lkml.org 
[lkml]   [2000]   [Jan]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRe: buggy GFP_KERNEL allocators
On Wed, 26 Jan 2000 kuznet@ms2.inr.ac.ru wrote:

>Hello!
>
>> + current->state = TASK_RUNNING; /* We *must* do this before touching userspace! */
>
>This smells suspiciously. Page fault code should not stuck only because
>task state is not running. It contaradicts all the idea behind wait queues.

Exactly. That was my whole point in one of my past emails.

>Essentially, fault is like signal. It must move task state to running.

Agreed.

I think the real fix for 2.2.15pre is this:

--- 2.2.15pre4/mm/page_alloc.c.~1~ Tue Jan 25 15:40:06 2000
+++ 2.2.15pre4/mm/page_alloc.c Thu Jan 27 09:51:35 2000
@@ -236,16 +236,6 @@
RMQUEUE_TYPE(order, 1);
spin_unlock_irqrestore(&page_alloc_lock, flags);

- /*
- * If we can schedule, do so, and make sure to yield.
- * We may be a real-time process, and if kswapd is
- * waiting for us we need to allow it to run a bit.
- */
- if (gfp_mask & __GFP_WAIT) {
- current->policy |= SCHED_YIELD;
- schedule();
- }
-
nopage:
return 0;
}

Doing such schedule make no sense at all. Each caller should have a fail
path that giveups. If we are oom and we don't giveup ASAP it means we'll
have more chances to cause an oom also for the following allocations.

With the above fix applyed all other patches become useless. In my tree
I'll take this approch.

Andrea


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:56    [W:0.081 / U:2.484 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site