Date: Sun, 17 Jun 2001 21:53:59 +0200 (MEST) From: Sascha Schumann <sascha@schumann.cx> To: Alfred Perlstein <bright@rush.net> Cc: Valentin Nechayev <netch@iv.nn.kiev.ua>, <freebsd-hackers@FreeBSD.ORG> Subject: Re: poll(2)'s arbitrary limit Message-ID: <Pine.LNX.4.33.0106172146470.6072-100000@rossini.schumann.cx> In-Reply-To: <20010617153129.N1832@superconductor.rush.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> You've misinterpreted the paper. :(
Sorry, I got the reference wrong. I was referring to a
recently published HP paper[1] which concluded that "contrary
to conventional wisdom, even a select based server can
provide high throughput if its overhead is amortized by
performing more useful work per select call."
This supported the results of benchmarks I conducted on
FreeBSD using select, poll and kqueue at the heart of the
State Threads implementation.
[1] http://www.hpl.hp.com/techreports/2000/HPL-2000-174.pdf
> As far as raising the amount of pollable entries, can you try your
> app with your kernel recompiled to accept 2xNO_FILE and 2xFD_SETSIZE
> and let us know if that solves your problem?
I've been using kern.maxproc=kern.maxprocfiles=2*32768 for my
tests and that worked successfully.
Thanks,
- Sascha Experience IRCG
http://schumann.cx/ http://schumann.cx/ircg
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?Pine.LNX.4.33.0106172146470.6072-100000>