Messages in this thread | | | Subject | Re: [RFC] per thread page reservation patch | From | Nikita Danilov <> | Date | Sun, 09 Jan 2005 21:16:24 +0300 |
| |
Marcelo Tosatti <marcelo.tosatti@cyclades.com> writes:
[...]
> > - all instances of an allocator from the current thread will eat from the perthread > reserves, you probably want only a few special allocations to eat from the reserves? > Thing is its not really a reservation intended for emergency situations, > rather a "generic per-thread pool" the way things are now.
Per-thread reservations are only useful when they are transparent. If users have to call special function, or to pass special flag to __alloc_pages() they might just use mempool as well. Idea is to reserve some number of pages before starting complex operation so that generic function (like find_get_page()) called as part of this operation are guaranteed to succeed.
> > - its a real fast path, we're adding quite some instructions there which are only > used by reiserfs now.
Yes, this worries me too. Possibly we should move this check below in __alloc_pages(), so that per-thread reservation is only checked if fast-path allocation failed.
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/
| |