[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Thread model

From: olafBuddenhagen
Subject: Re: Thread model
Date: Sun, 16 Mar 2008 08:01:22 +0100
User-agent: Mutt/1.5.17+20080114 (2008-01-14)


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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]