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/
This archive was generated by hypermail 2b29 : Mon Jan 31 2000 - 21:00:17 EST