Hi
PF_MEMDIE don't have any use in current kernels. Please
remove, we only set it in one place, and there we also set
PF_MEMALLOC. And we only test it in other place, and we also
test for PF_MEMALLOC. This patch has existed in aa for some
quite time.
Please apply.
Later, Juan.
diff -urNp ref/include/linux/sched.h 2.4.20pre5aa1/include/linux/sched.h
--- ref/include/linux/sched.h Fri Aug 30 01:55:20 2002
+++ 2.4.20pre5aa1/include/linux/sched.h Fri Aug 30 01:55:22 2002
@@ -481,7 +481,6 @@ struct task_struct {
#define PF_DUMPCORE 0x00000200 /* dumped core */
#define PF_SIGNALED 0x00000400 /* killed by a signal */
#define PF_MEMALLOC 0x00000800 /* Allocating memory */
-#define PF_MEMDIE 0x00001000 /* Killed for out-of-memory */
#define PF_FREE_PAGES 0x00002000 /* per process page freeing */
#define PF_NOIO 0x00004000 /* avoid generating further I/O */
diff -urNp ref/mm/oom_kill.c 2.4.20pre5aa1/mm/oom_kill.c
--- t3/mm/oom_kill.c.cc13-2.orig 2002-10-25 12:53:02.000000000 +0200
+++ t3/mm/oom_kill.c 2002-10-25 13:09:27.000000000 +0200
@@ -149,7 +149,7 @@ void oom_kill_task(struct task_struct *p
* exit() and clear out its resources quickly...
*/
p->counter = 5 * HZ;
- p->flags |= PF_MEMALLOC | PF_MEMDIE;
+ p->flags |= PF_MEMALLOC;
/* This process has hardware access, be more careful. */
if (cap_t(p->cap_effective) & CAP_TO_MASK(CAP_SYS_RAWIO)) {
diff -uNp t1/mm/page_alloc.c.cc13-3.orig t1/mm/page_alloc.c
--- t1/mm/page_alloc.c.cc13-3.orig 2003-01-08 23:32:31.000000000 +0100
+++ t1/mm/page_alloc.c 2003-01-08 23:40:26.000000000 +0100
@@ -351,7 +351,7 @@ struct page * __alloc_pages(unsigned int
/* here we're in the low on memory slow path */
rebalance:
- if (current->flags & (PF_MEMALLOC | PF_MEMDIE)) {
+ if (current->flags & PF_MEMALLOC) {
zone = zonelist->zones;
for (;;) {
zone_t *z = *(zone++);
--
In theory, practice and theory are the same, but in practice they
are different -- Larry McVoy
On Wed, 2003-01-08 at 17:47, Juan Quintela wrote:
> PF_MEMDIE don't have any use in current kernels. Please
> remove, we only set it in one place, and there we also set
> PF_MEMALLOC. And we only test it in other place, and we also
> test for PF_MEMALLOC. This patch has existed in aa for some
> quite time.
I independently thought this same thing, and did a patch for 2.5 which
had the same effect.
I was reminded by better-VM-hackers-than-I that PF_MEMALLOC can be
cleared in various paths so the PF_MEMDIE is required to ensure that the
check in page_alloc.c is always true for OOM'ed tasks.
Robert Love
>>>>> "robert" == Robert Love <[email protected]> writes:
robert> On Wed, 2003-01-08 at 17:47, Juan Quintela wrote:
>> PF_MEMDIE don't have any use in current kernels. Please
>> remove, we only set it in one place, and there we also set
>> PF_MEMALLOC. And we only test it in other place, and we also
>> test for PF_MEMALLOC. This patch has existed in aa for some
>> quite time.
robert> I independently thought this same thing, and did a patch for 2.5 which
robert> had the same effect.
robert> I was reminded by better-VM-hackers-than-I that PF_MEMALLOC can be
robert> cleared in various paths so the PF_MEMDIE is required to ensure that the
robert> check in page_alloc.c is always true for OOM'ed tasks.
That is a nice theory, and I think that this could be true in the
past, but in 2.4.2X, PF_MEMDIE only appears in the two places that I
show, and it is completely redundant, look at the patch, we are just
|-ing both PF_MEMALLOC and PF_MEMDIE and later we are &-ing against
the or of the two. Use find & grep yourself if you don't believe me.
Later, Juan.
--
In theory, practice and theory are the same, but in practice they
are different -- Larry McVoy
On Wed, 2003-01-08 at 18:49, Juan Quintela wrote:
> That is a nice theory, and I think that this could be true in the
> past, but in 2.4.2X, PF_MEMDIE only appears in the two places that I
> show, and it is completely redundant, look at the patch, we are just
> |-ing both PF_MEMALLOC and PF_MEMDIE and later we are &-ing against
> the or of the two. Use find & grep yourself if you don't believe me.
I realize this.
The issue is that PF_MEMALLOC can be _cleared_. In that case, if you
only set PF_MEMALLOC, that check can be false when we want it true. So
we need a flag that is more persistent.
PF_MEMDIE, which is not cleared on various allocation paths in the VM,
ensures that the check holds true for all OOM'ed tasks.
I thought the same as you, "hey this thing is worthless let us dump it",
and Rik and Andrew told me otherwise.
I am not saying you are wrong, though - I could be very wrong. But my
point is not what you say above; it is that the flag is needed because
just setting PF_MEMALLOC is insufficient since it can be unset.
Robert Love
>>>>> "robert" == Robert Love <[email protected]> writes:
robert> On Wed, 2003-01-08 at 18:49, Juan Quintela wrote:
>> That is a nice theory, and I think that this could be true in the
>> past, but in 2.4.2X, PF_MEMDIE only appears in the two places that I
>> show, and it is completely redundant, look at the patch, we are just
>> |-ing both PF_MEMALLOC and PF_MEMDIE and later we are &-ing against
>> the or of the two. Use find & grep yourself if you don't believe me.
robert> I realize this.
robert> The issue is that PF_MEMALLOC can be _cleared_. In that case, if you
robert> only set PF_MEMALLOC, that check can be false when we want it true. So
robert> we need a flag that is more persistent.
robert> PF_MEMDIE, which is not cleared on various allocation paths in the VM,
robert> ensures that the check holds true for all OOM'ed tasks.
robert> I thought the same as you, "hey this thing is worthless let us dump it",
robert> and Rik and Andrew told me otherwise.
robert> I am not saying you are wrong, though - I could be very wrong. But my
robert> point is not what you say above; it is that the flag is needed because
robert> just setting PF_MEMALLOC is insufficient since it can be unset.
I saw the light, thanks for the explanation.
Later, Juan.
--
In theory, practice and theory are the same, but in practice they
are different -- Larry McVoy