Re: Feedback on preemptible kernel patch

Daniel Phillips (phillips@bonn-fries.net)
Mon, 10 Sep 2001 20:25:44 +0200


On September 10, 2001 07:09 am, Robert Love wrote:
> On Sun, 2001-09-09 at 23:24, Daniel Phillips wrote:
> > This may not be your fault. It's a GFP_NOFS recursive allocation - this
> > comes either from grow_buffers or ReiserFS, probably the former. In
> > either case, it means we ran completely out of free pages, even though
> > the caller is willing to wait. Hmm. It smells like a loophole in vm
> > scanning.
>
> I am not a VM hacker -- can you tell me where to start? what do you
> suspect it is?
>
> If the user stops seeing the error with preemption disabled, is your
> theory nulled, or does that just mean the problem is agitated by
> preemption?
>
> I don't think Arjan was using ReiserFS, so its from grow_buffers...
>
> I appreciate your help.

The first thing to check is whether memory is really exhausted at the
time the errors are logged (cat /proc/meminfo). Then you want to see
which paths in __alloc_pages could possibly allow this PF_MEMALLOC +
GFP_WAIT allocation request to drop all the way through without being
serviced. Sorry, I haven't had time to do that and won't for a few
days. Even if you triggered it, it is probably a hole in the scan
logic. We have __GFP_WAIT, so it should wait.

Here's a hint, look very critically at this part of page_alloc.c:

455 /*
456 * Fail in case no progress was made and the
457 * allocation may not be able to block on IO.
458 */
459 return NULL;

--
Daniel
-
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/