Messages in this thread |  | | Subject | Re: Feedback on preemptible kernel patch | From | Robert Love <> | Date | 15 Sep 2001 15:18:16 -0400 |
| |
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.
Hi, Daniel. If you remember, a few users of the preemption patch reported instability and/or syslog messages such as:
Sep 9 23:08:02 sjoerd kernel: __alloc_pages: 0-order allocation failed (gfp=0x70/1). Sep 9 23:08:02 sjoerd last message repeated 93 times Sep 9 23:08:02 sjoerd kernel: cation failed (gfp=0x70/1). Sep 9 23:08:02 sjoerd kernel: __alloc_pages: 0-order allocation failed (gfp=0x70/1). Sep 9 23:08:02 sjoerd last message repeated 281 times
It now seems that all of them are indeed using ReiserFS. There are no other reported problems with the preemption patch, except from those users...
I am beginning to muse over the source, looking at when kmalloc is called with GFP_NOFS in ReiserFS, and then the path that code takes in the VM source.
I assume the kernel VM code has a hole somewhere, and the request is falling through? It should wait, even if no pages were free so, right?
Where should I begin looking? How does it relate to ReiserFS? How is preemption related?
Thank you very much,
-- Robert M. Love rml at ufl.edu rml at tech9.net
- 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/
|  |