lkml.org 
[lkml]   [1997]   [Mar]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: >256 fd patch...
Date
From

In message <9703201627.AA20113@dcl.MIT.EDU>, "Theodore Y. Ts'o" writes:
> I thought about that, but couldn't see a major win with it. The select
> code is already only copying FD's <= n, so the rest of the memory
> allocated is going unused, but other than that...
>
> I found that on my big machine, the caching of the last 10 kmallocs
> was to little. It actually had up to 24 select()'s sleeping at one
> time, so I increased the cache to 100 elements.
>
> Of course, this has negative implications for memory usage....
>
> Yes, but how many of the selects were using more than 32 file
> descriptors? If most of them are using less than 32, then using the
> statck for those cases *would* be a major memory win.

Ahh yes. It would be a major memory win (very few of them were using
more than 32 fd's), but from my point of view it would complicate the
patch, and slow it down. I belive it's more suited to be a kernel
compile option, than a permenant place in the kernel.

Michael.

\
 
 \ /
  Last update: 2005-03-22 13:39    [W:0.095 / U:0.092 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site