On Thu, Apr 21, 2005 at 02:10:44PM -0400, Marc E. Fiuczynski wrote: > > We are making some progress, but due to the learning curve required > > and time constraints we focused on the performance isolation aspect > > of the scheduler, so classes will get their guaranteed disk bandwidth > > share, > > Sounds great. Could you point me at the appropriate paper for cello.
I don't know the canonical URL, but you can get it from our class web page: http://www-users.itlabs.umn.edu/classes/Spring-2005/csci5980-1/papers/cello.pdf > Is the > algorithm it uses work preserving? I.e., if a class does not consume its > guarantee, is the available bandwidth handed to other classes? Yes, it is. > How many > classes can you support? We (PlanetLab) define on the order of 200 classes > per system. Can you support that many? We have not tried with that many and we might need to convert some linked lists to trees or hashes, but we have no inherent limitation. > > but within the class we will use the noop scheduler. > > By "within a class" you simply mean the procs that are members of the class, > right? Right. > How about hierarchy? Do you support that? We do, but the most interesting things get configured at the root of the hierarchies. Basically cello defines a two step scheme: a class independent scheduler that manages the master request queue and a bunch of class specific queues. Each class specific queue can have a different strategy for reordering the requests - the paper presents deadline, real-time and best effort. So, you can nest classes as long as you can justify the semantics: for instance if you have two classes A (real-time) and B (deadline) I would expect the children of A and B to be "best-effort" since I don't see what a real-time child can do if the parent is deadline, for instance. > > hope to continue it by making it more robust and > > migrating to at least the deadline scheduler. > > Not sure what you mean by this. Assume you have only one class - we will behave like the noop scheduler. Not something you want to put on a disk... unless it is solid-state. florin -- Don't question authority: they don't know either!
signature.asc
Description: Digital signature
