Date: Thu, 16 May 2002 17:22:33 -0700 From: Alfred Perlstein <bright@mu.org> To: Peter Wemm <peter@wemm.org> Cc: Doug White <dwhite@resnet.uoregon.edu>, Omar Thameen <omar@clifford.inch.com>, freebsd-hackers@FreeBSD.ORG Subject: Re: tuning a CPU bound server Message-ID: <20020517002233.GF20683@elvis.mu.org> In-Reply-To: <20020517001243.07997380A@overcee.wemm.org> References: <20020516224303.GA20683@elvis.mu.org> <20020517001243.07997380A@overcee.wemm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
* Peter Wemm <peter@wemm.org> [020516 17:12] wrote:
[snip about select collisions]
>
> FreeBSD's "bug" is is twofold:
> 1) we can only track one process selecting on a shared fd at one time, and
> 2) we never deregister selects.
Actually I think I did #2 under 5.x with 'sys_generic.c:clear_selinfo_list()'
:)
#1 is a bit of a PITA unless you do the linux thing or do some evil
stuff like storing several pids in the selinfo which gets really ugly.
> Tracking more than one is fine, but that either requires memory management
> as a result of making it dynamic (there is no point making space for 5 to
> select at once if we are failing with 600+ selecting at once). Memory
> management then requires that we have an opportunity to 'deselect' so that
> we can free up resources. Hmmm... We can do this lazily reuse and reclaim
> stale dynamic records the *next* time a new select happens or when the file
> is closed or something.
>
> The fundamental problem is that select() is supposed to be instantanious
> and stateless. kqueue solves it by seperating the register/deregister
> state from the checking of pending events so that we can keep the state
> active across the loops and avoid the expense of register/deregistering each
> time.
See how the code in 5.x does it :)
The only reason I didn't grow the selinfo to hold more threads/procs
is then I would have to drop the filedesc lock while scanning the
array which means I would have to do what linux does for each file:
loop {
lock filedesc,
lock file and bump refcount then unlock
unlock filedesc
make sure we have space for async wait channel
if not allocate
lock scheduler and add to async waitqueue
}
lock filedesc
fdrop all files gotten before and remove from async wait queue
it really seems like overkill for the case where you're doing the
right thing, ie, one big process select'ing/poll'ing on lots of
descriptors.
--
-Alfred Perlstein [alfred@freebsd.org]
'Instead of asking why a piece of software is using "1970s technology,"
start asking why software is ignoring 30 years of accumulated wisdom.'
Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020517002233.GF20683>