Messages in this thread Patch in this message | | | Date | Thu, 27 Jan 2000 09:57:29 +0100 (CET) | From | Andrea Arcangeli <> | Subject | Re: 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/
| |