lkml.org 
[lkml]   [1998]   [Jun]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Thread implementations...
Stephen C. Tweedie writes:
> Hi,
>
> On Tue, 30 Jun 1998 18:28:47 +1000, Richard Gooch
> <Richard.Gooch@atnf.CSIRO.AU> said:
> > See my previous response: with migrating FDs some threads have only a
> > small number of FDs to manage (active FDs) while other threads have
> > many FDs to manage (inactive FDs). When a FD becomes active
> > (i.e. wakes up poll(2)), it is moved to the active list. FDs on the
> > active list which haven't been active for the last N wakeups of
> > poll(2) are moved to the inactive list.
>
> OK, that sounds very reasonable.

Yeah, the point is to keep the "busy" FDs together to minimise polling
overheads. For "quiet" FDs, the polling overheads are higher, but that
is amortised over a larger number of FDs. Also, those overheads are
sort of once-off, as a FD that wakes up gets put on the active list.
I'm assuming that each FD becomes busy for a while (several wakeups of
poll(2)) and then goes inactive again. At any one time the total
number of FDs that are active is a small fraction of the total FDs.

I don't know if HTTP benchmarking programmes (traffic generators) have
this pattern or not, nor if my assumptions are related to reality. I
don't know how realistic the traffic generators are, either.
How well understood is the real world of HTTP traffic?

This is one reason why I'm glad we're getting O(1) kernel support, so
that at least for Linux this set of assumptions won't come back to
bite us.

> >> > I want to emphasise this point: I want to provide a scalable, portable
> >> > solution. ...
> >>
> >> Fine, but that doesn't mean we can't offer both!
>
> > Certainly! I'm all in favour of boosting the Linux performance. But at
> > the same time I'm writing a thin API that provides a callback
> > mechanism for when a FD is ready for reading/writing, and uses
> > migrating FDs if the OS can't provide an O(1) notification scheme. If
> > the O(1) support is there, I'll use it!
>
> OK -- if you will be providing a transparent wrapper which will offer
> access to that functionality, then it sounds a lot better. I think
> we're getting to the point of violent agreement here. :)

Shock horror ;-)

> However, I'd caution against specifying the interface exclusively in
> terms of callbacks. The posix.4 sigtimedwait() function is there
> explicitly to allow programs to perform a wait with timeout for an
> event, and to receive notification of the event _synchronously_ rather
> than via callback. That eliminates a good bit of unnecessary cost in
> many cases.

Well, my interface is still synchronous (the main thread explicitely
calls the polling function, which scans the active FDs and then calls
the callbacks). I'm planning for the possibility of multiple active
lists, each managed by a thread, but that's for later. The advantage
of the callback interface is that you register an arbitrary pointer
with each managed FD, so it's easy to link application-specific state
for each FD. And the interface does specify a timeout for the main
polling function, too.

Can you elaborate on the costs you're referring to?

Regards,

Richard....

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

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