On 25 Nov 2002, Robert Love wrote:
> PF_MEMDIE seems to serve no needed purpose in 2.5. In fact, it seems it
> has no point in 2.4, either.
>
> Attached patch, against 2.5.49-mm1, makes PF_MEMDIE die.
What makes you say no needed purpose? I agree it's screwed in 2.5,
but its purpose is to make more memory available to the OOMkilled task,
so it's not held up on its way out to freeing memory: seems reasonable.
I'm no great lover of PF_MEMDIE and PF_ flag manipulation, but let it
live until we have an alternative? I think the better patch is not
to lose PF_MEMDIE (and conceivably others) once it has been set.
(Shall we agree to turn a blind eye to the risk of oom_kill_task
manipulating p->flags while it may be another CPU's current->flags?)
Hugh
--- 2.5.49-mm1/mm/page_alloc.c Sat Nov 23 10:18:53 2002
+++ linux/mm/page_alloc.c Mon Nov 25 11:54:27 2002
@@ -432,7 +432,8 @@
current->flags |= PF_MEMALLOC;
ret = try_to_free_pages(classzone, gfp_flags, order);
- current->flags = cflags;
+ if (!(cflags & PF_MEMALLOC))
+ current->flags &= ~PF_MEMALLOC;
return ret;
}
--- 2.5.49-mm1/mm/swap_state.c Tue Nov 5 00:03:10 2002
+++ linux/mm/swap_state.c Mon Nov 25 12:08:40 2002
@@ -120,6 +120,7 @@
{
swp_entry_t entry;
int pf_flags;
+ int err;
if (!PageLocked(page))
BUG();
@@ -149,9 +150,15 @@
/*
* Add it to the swap cache and mark it dirty
*/
- switch (add_to_page_cache(page, &swapper_space, entry.val)) {
+ err = add_to_page_cache(page, &swapper_space, entry.val);
+
+ if (!(pf_flags & PF_NOWARN))
+ current->flags &= ~PF_NOWARN;
+ if (pf_flags & PF_MEMALLOC)
+ current->flags |= PF_MEMALLOC;
+
+ switch (err) {
case 0: /* Success */
- current->flags = pf_flags;
SetPageUptodate(page);
ClearPageDirty(page);
set_page_dirty(page);
@@ -159,13 +166,11 @@
return 1;
case -EEXIST:
/* Raced with "speculative" read_swap_cache_async */
- current->flags = pf_flags;
INC_CACHE_INFO(exist_race);
swap_free(entry);
continue;
default:
/* -ENOMEM radix-tree allocation failure */
- current->flags = pf_flags;
swap_free(entry);
return 0;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Nov 30 2002 - 22:00:10 EST