Messages in this thread | | | From | Nikita Danilov <> | Date | Sat, 6 Nov 2004 19:54:12 +0300 | Subject | Re: [PATCH] Remove OOM killer from try_to_free_pages / all_unreclaimable braindamage |
| |
Andrea Arcangeli writes: > On Sat, Nov 06, 2004 at 02:37:05PM +0300, Nikita Danilov wrote: > > We need page-reservation API of some sort. There were several attempts > > to introduce this, but none get into mainline. > > they're already in under the name of mempools
I am talking about slightly different thing. Think of some operation that calls find_or_create_page(). find_or_create_page() doesn't know about memory reserved in mempools, it uses alloc_page() directly. If one wants to guarantee that compound operation has enough memory to complete, memory should be reserved at the lowest level---in the page allocator.
> > I'm perfectly aware the fs tends to be the less correct places in terms > of allocations, and luckily it's not an heavy memory user, so I still
Either you are kidding, or we are facing very different workloads. In the world of file-system development, file-system is (not surprisingly) single largest memory consumer.
> have to see a deadlock in getblk or create_buffers or similar. It's > mostly a correctness issue (math proof it can't deadlock, right now it > can if more tasks all get stuck in getblk at the same time during a hard > oom condition etc..).
Add here mmap that can dirty all physical memory behind your back, and delayed disk block allocation that forces ->writepage() to allocate potentially huge extent when memory is already tight and hope of having a proof becomes quite remote.
Nikita. - 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/
| |