[patch-2.3.40-pre6] nfds limit for poll() raised to 131 million (is that enough?)

[Jamie Lokier]

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 en vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/