> > > There are few problems if we aggressively cleanup the lru lists. > > > - we may be throwing the pages out which may be pulled in > > > by the task in very near future. > > > > This is only the case if the processes within the same class > > approach or exceed the memlimit. > > Wouldn't that be the most often case ?
In our system we have on the order of 200 classes. Most of these classes stay well within their memory limit. There are a few that push the memory limit, and it is those that I'd prefer to penalize. > > > > > > - if a class need lot more than the limit, we will be > > > swapping bigtime to the disk, which would slow down > > > the other processes in the system > > > > Why? Because the class is consuming too much I/O bandwidth? > Well, that's > > yes, that is why... > > what a working I/O controller should solve, right? > > In the absence of a I/O controller, other classes would be > affected for no fault of their own.. Agreed... which is why CKRM needs a working I/O controller (either Shailab's or the folks working on Cello). Marc ------------------------------------------------------- This SF.Net email is sponsored by: New Crystal Reports XI. Version 11 adds new functionality designed to reduce time involved in creating, integrating, and deploying reporting solutions. Free runtime info, new features, or free trial, at: http://www.businessobjects.com/devxi/728 _______________________________________________ ckrm-tech mailing list https://lists.sourceforge.net/lists/listinfo/ckrm-tech
