![]() | |||||||||||||
Messages in this thread |
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/ | ||||||||||||
| Last update: 2005-11-21 06:56 [from the cache] ©2003-2008 | |||||||||||||