Messages in this thread | | | Date | Wed, 1 Jul 1998 11:33:16 +1000 | From | Richard Gooch <> | Subject | Re: 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
| |