Tigran Aivazian wrote:
> On Thu, 20 Jan 2000, Tigran Aivazian wrote:
> > Does Alan have any preference or are we all working in the wrong direction
> > and he prefers kmalloc/vmalloc split (or some other) idea?
>
> For example, some other idea may be to create a pollfd_cache slab cache
> at system initialization and have poll() allocate/free objects from it as
> needed. May even be faster than what we currently have?
Excellent idea! Reasons:
- Save memory. I estimate about 100k on my single-user PC!
Most tasks poll/select very few descriptors. It's quite common
to have a /lot/ of tasks all blocked in poll or select.
E.g. all X applications. Why waste a page on each one, when
only a few bytes are required? Use a slab cache and save
approx. 1 page per blocked task.
- Cache line interference
The current implementation bangs the same places in different
pages for different tasks doing poll() at the same time. This
leads to cache line collisions. A slab cache would relieve that.
- No fd limit, for free
To keep it scalable on SMP, you'd want a per-processor slab cache.
-- Jamie
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Jan 23 2000 - 21:00:22 EST