Hi, On Tue, Mar 11, 2008 at 12:10:17PM +0100, Neal H. Walfield wrote:
> > using some kind of continuation mechanism: Have a limited number of > > threads (ideally one per CPU) handle incoming requests. Whenever > > some operation would require blocking for some event (in the case of > > diskfs, waiting for the underlying store to finish reading/writing), > > the state is instead saved to some list of outstanding operations, > > and the thread goes on handling other requests. Only when the event > > completes, we read the state back and continue handling the original > > request. > > What you are suggesting is essentially using a user-level thread > package. (Compacting a thread's state in the form of a closure is a > nice optimization, but the model essentially remains the same.) The > main advantage to user-level thread package is that the thread memory > is pagable and is thus less likely to exhaust the sparser kernel > resources. In the end, however, it suffers from the same problems as > the current approach. I don't agree it's equivalent -- not in any meaningful sense. The fact that the resources are allocated in the server not the kernel makes a very big difference. Not only is the memory pagable, as you pointed out, but also all virtual memory can be used, rather than just the limited zone memory. Even more importantly, when the memory is exhausted, it doesn't result in a kernel panic, but only in the server failing -- a much more pleasent scenario, especially if it's a non-critical server. As for the closures, they don't make a difference formally, but quite a huge one quantitatively: It requires several orders of magnitude less memory. And of course, the programming model is very different -- but that doesn't matter for the question at hand. All in all, several million outstanding requests should be possible with this approach. Of course, it doesn't prevent DOS (accidental or intentional), but it is enough to avoid resource exhaustion in normal use. Introducing some per-process/per-user limits could help catching the worst issues -- not elegant, but useful. > The approach that I am taking on Viengoos is to expose an interface > that is atomic and restartable. [...] This is a very interesting approach. It could very well be a desirable long-term goal; I'm eager to see how it will work out in practice. But it's a much more fundamental change. We need to start somewhere. -antrik-
