From: Andrea Righi <righi.andrea-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Randy Dunlap <randy.dunlap-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
Cc: axboe-tSWWG44O7X1aa/9Udqfwiw@public.gmane.org,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org,
containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Carl Henrik Lunde
<chlunde-om2ZC0WAoZIXWF+eFR7m5Q@public.gmane.org>,
Divyesh Shah <dpshah-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
matt-cT2on/YLNlBWk0Htik3J/w@public.gmane.org,
Paul Menage <menage-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>,
roberto-5KDOxZqKugI@public.gmane.org,
Balbir Singh
<balbir-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
Subject: Re: [PATCH 1/3] i/o bandwidth controller documentation
Date: Sat, 21 Jun 2008 12:35:02 +0200 [thread overview]
Message-ID: <485CD956.3070209@gmail.com> (raw)
In-Reply-To: <20080620100825.eff22c44.randy.dunlap-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
Thanks Randy, I've applied all your fixes to my local documentation,
next patchset version will include them. A few small comments below.
Randy Dunlap wrote:
>> +* Run a benchmark doing I/O on /dev/sda1 and /dev/sda5; I/O limits and usage
>> + defined for cgroup "foo" can be shown as following:
>> + # cat /mnt/cgroup/foo/blockio.bandwidth
>> + === device (8,1) ===
>> + bandwidth limit: 1024 KiB/sec
>> + current i/o usage: 819 KiB/sec
>> + === device (8,5) ===
>> + bandwidth limit: 1024 KiB/sec
>> + current i/o usage: 3102 KiB/sec
>
> Ugh, this makes it look like the output does "pretty printing" (formatting),
> which is generally not a good idea. Let some app be responsible for that,
> not the kernel. Basically this means don't use leading spaces just to make the
> ":"s line up in the output.
Sounds reasonable. I think the output could be further reduced,
the following format should be explanatory enough.
device: %u,%u
bandwidth: %lu KiB/sec
usage: %lu KiB/sec
>> +WARNING: per-block device limiting rules always refer to the dev_t device
>> +number. If a block device is unplugged (i.e. a USB device) the limiting rules
>> +associated to that device persist and they are still valid if a new device is
>
> associated with (?)
what about:
...the limiting rules defined for that device...
-Andrea
WARNING: multiple messages have this Message-ID (diff)
From: Andrea Righi <righi.andrea@gmail.com>
To: Randy Dunlap <randy.dunlap@oracle.com>
Cc: Balbir Singh <balbir@linux.vnet.ibm.com>,
Paul Menage <menage@google.com>,
Carl Henrik Lunde <chlunde@ping.uio.no>,
axboe@kernel.dk, matt@bluehost.com, roberto@unbit.it,
Divyesh Shah <dpshah@google.com>,
akpm@linux-foundation.org, containers@lists.linux-foundation.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/3] i/o bandwidth controller documentation
Date: Sat, 21 Jun 2008 12:35:02 +0200 [thread overview]
Message-ID: <485CD956.3070209@gmail.com> (raw)
In-Reply-To: <20080620100825.eff22c44.randy.dunlap@oracle.com>
Thanks Randy, I've applied all your fixes to my local documentation,
next patchset version will include them. A few small comments below.
Randy Dunlap wrote:
>> +* Run a benchmark doing I/O on /dev/sda1 and /dev/sda5; I/O limits and usage
>> + defined for cgroup "foo" can be shown as following:
>> + # cat /mnt/cgroup/foo/blockio.bandwidth
>> + === device (8,1) ===
>> + bandwidth limit: 1024 KiB/sec
>> + current i/o usage: 819 KiB/sec
>> + === device (8,5) ===
>> + bandwidth limit: 1024 KiB/sec
>> + current i/o usage: 3102 KiB/sec
>
> Ugh, this makes it look like the output does "pretty printing" (formatting),
> which is generally not a good idea. Let some app be responsible for that,
> not the kernel. Basically this means don't use leading spaces just to make the
> ":"s line up in the output.
Sounds reasonable. I think the output could be further reduced,
the following format should be explanatory enough.
device: %u,%u
bandwidth: %lu KiB/sec
usage: %lu KiB/sec
>> +WARNING: per-block device limiting rules always refer to the dev_t device
>> +number. If a block device is unplugged (i.e. a USB device) the limiting rules
>> +associated to that device persist and they are still valid if a new device is
>
> associated with (?)
what about:
...the limiting rules defined for that device...
-Andrea
next prev parent reply other threads:[~2008-06-21 10:35 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-20 10:05 [PATCH 1/3] i/o bandwidth controller documentation Andrea Righi
[not found] ` <1213956335-29866-2-git-send-email-righi.andrea-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2008-06-20 17:08 ` Randy Dunlap
2008-06-20 17:08 ` Randy Dunlap
[not found] ` <20080620100825.eff22c44.randy.dunlap-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
2008-06-21 10:35 ` Andrea Righi [this message]
2008-06-21 10:35 ` Andrea Righi
[not found] ` <485CD956.3070209-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2008-06-22 16:03 ` Randy Dunlap
2008-06-22 16:03 ` Randy Dunlap
-- strict thread matches above, loose matches on Subject: below --
2008-07-04 13:58 Andrea Righi
2008-07-04 13:58 Andrea Righi
[not found] <200806201602.m5KG2Zx32671@inv.it.uc3m.es>
2008-06-20 16:11 ` Peter T. Breuer
2008-07-04 15:35 ` Andrea Righi
2008-06-20 10:05 Andrea Righi
2008-06-06 22:27 Andrea Righi
2008-06-11 22:42 ` Randy Dunlap
2008-06-11 22:51 ` Andrea Righi
2008-06-18 15:16 ` Carl Henrik Lunde
2008-06-18 22:28 ` Andrea Righi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=485CD956.3070209@gmail.com \
--to=righi.andrea-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
--cc=akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \
--cc=axboe-tSWWG44O7X1aa/9Udqfwiw@public.gmane.org \
--cc=balbir-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org \
--cc=chlunde-om2ZC0WAoZIXWF+eFR7m5Q@public.gmane.org \
--cc=containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
--cc=dpshah-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=matt-cT2on/YLNlBWk0Htik3J/w@public.gmane.org \
--cc=menage-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org \
--cc=randy.dunlap-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org \
--cc=roberto-5KDOxZqKugI@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.