lkml.org 
[lkml]   [1997]   [Mar]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: >256 fd patch...
   Date: Thu, 20 Mar 1997 09:12:47 +0800
From: "Michael O'Reilly" <michael@metal.iinet.net.au>

> The cacheing is definitely a good thing. The other thing you can do is
> to put in a special case check for n < 32 and use automatic variables
> allocated on the stack for that case. This should be a big win, since
> a very large number of calls to select use n < 32.
> - Ted
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.

- Ted

\
 
 \ /
  Last update: 2005-03-22 13:39    [from the cache]
©2003-2011 Jasper Spaans