[libvirt] [PATCH] doc: blkio: add some notification
If the I/O elevator of disk is not cfq, the setting of blkio.weight is ineffective. And the setting up blkio.weight_device will fail. Add notification for this situation. Signed-off-by: Gao feng <gaofeng@cn.fujitsu.com> --- docs/formatdomain.html.in | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in index 47d91ab..8d048be 100644 --- a/docs/formatdomain.html.in +++ b/docs/formatdomain.html.in @@ -740,7 +740,8 @@ <dd> The optional <code>blkiotune</code> element provides the ability to tune Blkio cgroup tunable parameters for the domain. If this is omitted, it defaults to the OS provided - defaults. <span class="since">Since 0.8.8</span></dd> + defaults. Notice: blkiotune is effective only when the I/O elevator + of disk is cfq. <span class="since">Since 0.8.8</span></dd> <dt><code>weight</code></dt> <dd> The optional <code>weight</code> element is the overall I/O weight of the guest. The value should be in the range [100, @@ -761,7 +762,8 @@ mandatory sub-elements, <code>path</code> describing the absolute path of the device, and <code>weight</code> giving the relative weight of that device, in the range [100, - 1000]. <span class="since">Since 0.9.8</span></dd> + 1000]. The setting up device.weight will fail if the I/O elevator + of this disk device is not cfq. <span class="since">Since 0.9.8</span></dd> </dl> -- 1.8.1.4
On 07/02/2013 02:44 AM, Gao feng wrote:
If the I/O elevator of disk is not cfq, the setting of blkio.weight is ineffective. And the setting up blkio.weight_device will fail.
Add notification for this situation.
Signed-off-by: Gao feng <gaofeng@cn.fujitsu.com> --- docs/formatdomain.html.in | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in index 47d91ab..8d048be 100644 --- a/docs/formatdomain.html.in +++ b/docs/formatdomain.html.in @@ -740,7 +740,8 @@ <dd> The optional <code>blkiotune</code> element provides the ability to tune Blkio cgroup tunable parameters for the domain. If this is omitted, it defaults to the OS provided - defaults. <span class="since">Since 0.8.8</span></dd> + defaults. Notice: blkiotune is effective only when the I/O elevator + of disk is cfq. <span class="since">Since 0.8.8</span></dd>
This is terminology specific to the Linux kernel; would it help to add a phrase explaining that? Maybe something like: Notice: blkiotune is effective only when the host kernel uses the 'cfq' I/O elevator for the disk. I like the idea of the patch, but am not sure that I know enough about kernel internals to state whether your wording or my alternative is good enough at getting the point across correctly to someone else not very familiar with kernel concepts. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
On 07/03/2013 03:01 AM, Eric Blake wrote:
On 07/02/2013 02:44 AM, Gao feng wrote:
If the I/O elevator of disk is not cfq, the setting of blkio.weight is ineffective. And the setting up blkio.weight_device will fail.
Add notification for this situation.
Signed-off-by: Gao feng <gaofeng@cn.fujitsu.com> --- docs/formatdomain.html.in | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/docs/formatdomain.html.in b/docs/formatdomain.html.in index 47d91ab..8d048be 100644 --- a/docs/formatdomain.html.in +++ b/docs/formatdomain.html.in @@ -740,7 +740,8 @@ <dd> The optional <code>blkiotune</code> element provides the ability to tune Blkio cgroup tunable parameters for the domain. If this is omitted, it defaults to the OS provided - defaults. <span class="since">Since 0.8.8</span></dd> + defaults. Notice: blkiotune is effective only when the I/O elevator + of disk is cfq. <span class="since">Since 0.8.8</span></dd>
This is terminology specific to the Linux kernel; would it help to add a phrase explaining that? Maybe something like:
Notice: blkiotune is effective only when the host kernel uses the 'cfq' I/O elevator for the disk.
Yes, this looks better.
I like the idea of the patch, but am not sure that I know enough about kernel internals to state whether your wording or my alternative is good enough at getting the point across correctly to someone else not very familiar with kernel concepts.
take easy, I'm working on enhancing the warn/error log for libvirt in this situation. I think it's clear enough if we provide some logs to the user.
participants (2)
-
Eric Blake -
Gao feng