Hi Shailabh,
Took a look at your documentation on using the I/O controller. I can see
how one might use the I/O controller if one had a few classes. E.g., the
gold, silver, and bronze class of I/O based processes (or maybe up to ~20
classes). However, in my environment I may potentially have hundreds of
vservers.
There are two constraints here: a) the number of classes that CKRM as a whole can effectively support and b) the number of I/O priorities that can be effectively distinguished.
For a), while designing CKRM we planned on handling ten's of classes, not hundreds. While it may still be possible to do so, I'm guessing the overheads would start getting quite high. So mapping each vserver to a separate class may not be efficient or effective. Is it possible to group vservers into coarser groupings that should be performance isolated from each other ? Within a grouping, there would be no protection.
In b), the current constraint is that only about 20 distinct levels of bandwidth splitting are supported (in increments of 5%). Assuming each class gets a minimum allocation of 5%, yes, only 19 can be supported (prio level 20 will actually starve the rest so shouldn't be used - thats a bug that needs to be fixed). This is a limitation of the underlying CFQ. However, one can define more than 20 classes - the rest will have to be assigned I/O priority = 0 which does not mean no service but service only when there are no pending requests in the other priority levels.
While we could get into more fine-grained splitting, its very unlikely that it'll go below the 1% level so we'll still have a problem for allowing hundreds of distinct service levels.
What I was hoping for was a means to isolate one vserver's I/O
bandwidth consumption from that of other vserver. I.e., something more like
a proportional share of the I/O bandwidth.
Were you planning on allocating 100/n % of the bandwidth to each, where n is the number of vservers ?
For this reason, I was expecting that I could create a one-to-one mapping between each vserver and a new class and give each vserver a share. It is not obvious to me how I would do that using your scheme.
Hubertus/Haoqiang,Chandra, Vivek, could you give an estimate of how many distinct classes CPU, mem and listen queue controllers can support ?
If they are very different and much greater than 20, then one workaround for the I/O controllers can be pursued: CFQ doesn't limit the number of entities at a given priority level. So its possible to have 95 classes, with 5 each at priority levels 1 through 19. At each level, the 5 would get equal service (theoretically) and collectively get the % share implied by the level (1=5%, 2=10% etc.)
This means I would need to use the shares interface to directly specify the I/O priority level (which would allow any number of classes at level=1=5%, say, rather than only 20).
Changing the I/O controller to do this would be simple enough but our abstraction of allocating a 100% hierarchically would be broken.
Of course, it is entirely possible that I simply misunderstood the way one can use the I/O controller. In what way do you suggest I assign I/O shares to each of these vservers?
Let me get out patch implementing the suggestion above which would free you from the 20 class limitation.
Meanwhile, could you comment on the stability of the patch ? Do you have problems compiling/running ?
Regards, Shailabh
Best regards, Marc
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Shailabh Nagar Sent: Tuesday, September 21, 2004 7:00 PM To: Marc Fiuczynski Cc: ckrm-tech Subject: [ckrm-tech] I/O controller for e16
Here is another attempt to get the I/O controller working for e16.
On my P4 SMT box, I'm able to run tiobench's in different classes though I don't observe a significant differentiation between the priority levels. OTOH, the depth of the I/O request queues formed by tiobench is pretty small so that needs to be eliminated as a cause by using an aio-based test.
Please give it a spin. There's rudimentary documentation included in the patch.
Marc, I'm getting onto the differentiation resolution now. Let me know if this controller creates problems like last time...
Regards, Shailabh
------------------------------------------------------- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php _______________________________________________ ckrm-tech mailing list https://lists.sourceforge.net/lists/listinfo/ckrm-tech
