Messages in this thread | | | Date | Sun, 20 Nov 2005 21:53:52 -0800 | From | Matthew Dobson <> | Subject | Re: [RFC][PATCH 0/8] Critical Page Pool |
| |
Keith Owens wrote: > On Fri, 18 Nov 2005 11:32:57 -0800, > Matthew Dobson <colpatch@us.ibm.com> wrote: > >>We have a clustering product that needs to be able to guarantee that the >>networking system won't stop functioning in the case of OOM/low memory >>condition. The current mempool system is inadequate because to keep the >>whole networking stack functioning, we need more than 1 or 2 slab caches to >>be guaranteed. We need to guarantee that any request made with a specific >>flag will succeed, assuming of course that you've made your "critical page >>pool" big enough. >> >>The following patch series implements such a critical page pool. It >>creates 2 userspace triggers: >> >>/proc/sys/vm/critical_pages: write the number of pages you want to reserve >>for the critical pool into this file >> >>/proc/sys/vm/in_emergency: write a non-zero value to tell the kernel that >>the system is in an emergency state and authorize the kernel to dip into >>the critical pool to satisfy critical allocations. > > > FWIW, the Kernel Debugger (KDB) has similar problems where the system > is dying because of lack of memory but KDB must call some functions > that use kmalloc. A related problem is that sometimes KDB is invoked > from a non maskable interrupt, so I could not even trust the state of > the spinlocks and the chains in the slab code. > > I worked around the problem by adding a last ditch allocator. Extract > from the kdb patch.
Ahh... very interesting. And dissapointingly much smaller than mine. :(
Thanks for the patch and the feedback!
-Matt - 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/
| |