disk throttling

disk throttling

[Tim Freeman]

Please forgive me if this has been asked recently, is there support or 
plans for disk accounting and/or throttling?  e.g., certain domains can 
only read/write so much/so often to certain disks/partitions?

Thanks!

Tim

p.s., congratulations on the release!


-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click

Re: disk throttling

[Mark A. Williamson]

There are plans for some improved disk QoS (I think it's on the roadmap).  The 
current mode of disk scheduling doesn't differentiate different service 
qualities.  I don't *think* it does accounting yet (this'd likely be added at 
the same time).

Unlike for network, there wasn't a standard Linux way to do this.  Maybe the 
pluggable Linux IO schedulers framework (possible merge in 2.6.10) would help 
with this work.

HTH,
Mark

On Thursday 11 Nov 2004 17:26, Tim Freeman wrote:
> Please forgive me if this has been asked recently, is there support or
> plans for disk accounting and/or throttling?  e.g., certain domains can
> only read/write so much/so often to certain disks/partitions?
>
> Thanks!
>
> Tim
>
> p.s., congratulations on the release!
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Sybase ASE Linux Express Edition - download now for FREE
> LinuxWorld Reader's Choice Award Winner for best database on Linux.
> http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/xen-devel


-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click

Re: disk throttling

[Jacob Gorm Hansen]

Mark A. Williamson wrote:
> There are plans for some improved disk QoS (I think it's on the roadmap).  The 
> current mode of disk scheduling doesn't differentiate different service 
> qualities.  I don't *think* it does accounting yet (this'd likely be added at 
> the same time).
> 
> Unlike for network, there wasn't a standard Linux way to do this.  Maybe the 
> pluggable Linux IO schedulers framework (possible merge in 2.6.10) would help 
> with this work.
> 

Has the plan of turning Xen into a next-gen BIOS been scrapped? It seems 
Xen is becoming more and more dependent on having a specific version of 
Linux as dom0?

Jacob


-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click

Re: disk throttling

[Mark A. Williamson]

> Has the plan of turning Xen into a next-gen BIOS been scrapped? It seems
> Xen is becoming more and more dependent on having a specific version of
> Linux as dom0?

Our proposed next-gen architecture now consists of:
* Safe Hardware Interface - restricted access to machine resources (memory, IO 
regions...).  Provided by Xen itself.
* Next gen "BIOS controller" - general machine management...  It runs all the 
time rather than just at bootup.
* Driver domains - device drivers scheduled pre-emptively, with restricted 
hardware access
* Virtual machines - run user applications

Currently, the duties of the next gen BIOS controller and driver domains are 
both in dom0 but these functions can be split into separate domains if 
desired.

But both Xen and the dom0 functionality is now notionally part of the 
"BIOS" (obviously you might not want ot use a full featured Linux in dom0 if 
you were really using this as a BIOS!!!) in the model.

It's not clear that the pluggable schedulers framework would give us the 
functionality we'd want anyhow.  If it was useful, it wouldn't make dom0 
dependent on a specific version of Linux - it'd just mean the 2.6 port 
offered more functionality as a dom0.  If it wasn't useful and we rolled our 
own, it may well end up in 2.4 too.

Cheers,
Mark


-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click

Re: disk throttling

[Jacob Gorm Hansen]

Mark A. Williamson wrote:
>>Has the plan of turning Xen into a next-gen BIOS been scrapped? It seems
>>Xen is becoming more and more dependent on having a specific version of
>>Linux as dom0?
> 
> 
> Our proposed next-gen architecture now consists of:
> * Safe Hardware Interface - restricted access to machine resources (memory, IO 
> regions...).  Provided by Xen itself.
> * Next gen "BIOS controller" - general machine management...  It runs all the 
> time rather than just at bootup.
> * Driver domains - device drivers scheduled pre-emptively, with restricted 
> hardware access
> * Virtual machines - run user applications

In this setup, where would stuff like the net filter be placed? In the 
network driver domain? How would one register the IP address of a new 
domain?

It would be really cool to be able to run without a full Linux just for 
drivers.  How much work do you think it would be to port one of the 
pre-NGIO Xen drivers to run in a separate VM?

I know you guys focus primarily on server-class machines, but I am 
dreaming of running Xen on a 1000+ node cluster we have here, and with 
the current mem usage of dom0 (according to postings on this list it has 
a hard time coping on 32megs or less), this would waste at least 32 
gigabytes of mem, just for dom0s.

Jacob


-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click

Re: disk throttling

[Mark A. Williamson]

> In this setup, where would stuff like the net filter be placed? In the
> network driver domain? How would one register the IP address of a new
> domain?

The driver is probably the best place to put filtering from a performance 
standpoint.  IP setup could be done by defining some new control messages and 
sending them directly to the driver domain.

You can (in theory) run a net frontend and a backend in the same domain, which 
would allow you to construct something like:

(user VM [vif front])
<->
([vif back] net filtering VM [vif front])
<->
([vif back] driver domain [hardware])

So there's a intermediary third VM doing the filtering.  This would 
unfortunately cost you some performance, although I don't have any numbers.  
I think some groundwork has been laid for doing this already but I'm not sure 
if it can actually be done yet.

> It would be really cool to be able to run without a full Linux just for
> drivers.  How much work do you think it would be to port one of the
> pre-NGIO Xen drivers to run in a separate VM?

Well, the pre-NGIO drivers are basically just Linux drivers with some (varying 
quantity of) tweaks.  Xen provided them with a Linux-like environment to make 
porting easy.  There was talk of modifying the mini-OS to pull in enough of a 
Linux env to support some drivers in a very small memory footprint, which 
might be a good way of tackling this.

Driver domains could run in 3meg anyhow if they don't have any userspace, so 
this isn't going to get huge savings.

> I know you guys focus primarily on server-class machines, but I am
> dreaming of running Xen on a 1000+ node cluster we have here, and with
> the current mem usage of dom0 (according to postings on this list it has
> a hard time coping on 32megs or less), this would waste at least 32
> gigabytes of mem, just for dom0s.

Woah!  Really cool ;-)  And yes, the 32 gig memory footprint is scary.  OTOH, 
you've probably got a couple of terabytes of ram!  I guess the best way if 
you really want to save memory would be a lightweight (possibly more 
specialised) Xend, to enable much smaller dom0s.

Cheers,
Mark


-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click

Re: disk throttling

[Keir Fraser]

> I know you guys focus primarily on server-class machines, but I am 
> dreaming of running Xen on a 1000+ node cluster we have here, and with 
> the current mem usage of dom0 (according to postings on this list it has 
> a hard time coping on 32megs or less), this would waste at least 32 
> gigabytes of mem, just for dom0s.

Yes, but it's still the same fraction of total memory. If you can
afford a 1000-node cluster with terabytes of RAM then 32GB is utterly
inconsequential.

 -- Keir


-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8

Re: disk throttling

[Steven Hand]

> Has the plan of turning Xen into a next-gen BIOS been scrapped? It seems 
> Xen is becoming more and more dependent on having a specific version of 
> Linux as dom0?

As you know, Xen itself isn't dependent on anything much -- but a
machine with just Xen and no domain 0 doesn't actually do anything. 
Any domain 0 which can provide the requisite functionality
(control tools and backends mainly) is fine -- we're currently using
linux 2.6.9 for this as it seems the logical choice (lots of
functionality, mature code base, widespread user knowledge).

If someone wants to write a 'custom' OS for dom0 to address some 
perceived overhead, then they should feel free to. It probably 
could be quite a lot smaller than linux. 

Even in this case, however, we're extremely likely to retain linux
2.6.x as a recommended backend platform due to the wide-ranging
hardware support. The 1.2-style notion of writing new drivers to run
within Xen is effectively untenable unless folks are prepared to spend
a hell of a lot of time writing + testing driver code...

cheers,

S.




-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click