Re: An attempt at optimising the poll code

On Fri, Aug 04, 2000, Alex Rousskov wrote:
> On Fri, 4 Aug 2000, Henrik Nordstrom wrote:
>
> > Tricky thing this.. but I am more and more convinced that a priority
> > based algorithm is the way to go. The higher the priority, the shorter
> > the timeout. And lower priorities should include the higher priority
> > filedescriptors in their polls.
>
> Just to share a bit of real-life experience with optimizing poll(2) in
> Web Polygraph... I found that the best way is to leave it up to the poll
> "user" to decide what FDs are assigned what priority. In many cases, the
> user knows better whether a particular FDs is hot or cold. A user may,
> of course, call simply rely on the opinion of low-level routines if
> needed.

Yup, I agree - one optimisation I thought about was polling deferred fd's
less than normal to let the client filedescriptors be flushed. But it
would be easier if there was more information passed to the event IO
loop to decide which poll() queue to place it into.

[snip]

> $0.02,

Appreciated. :-)

>
> Alex.
>
> P.S. If you split all FDs in groups and never poll all of them at once,
> be careful on how you select your timeout. Simply using the timeout
> suggested by the event queue will no longer work. The latter is
> one of the reasons for polling all FDs in Polygraph -- it
> simplifies the logic and eliminates one parameter from the model,
> sort of.

Well, there is magic in the poll code to select the timeout which has
been simply carried over into the new code without modification. I
think there might be a little room for improvement in the accept socket
poll()ing, but again, patches and benchmarks are accepted. :-)

Thanks for your comments!

Adrian

-- 
Adrian Chadd			"If Pascal was elite it would be cool,
<adrian@creative.net.au>	 but it isn't, so its not."
					-Joshua Goodall