From: Mike Snitzer <snitzer-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: Nikolay Borisov <n.borisov-/eCPMmvKun9pLGFMi4vTTA@public.gmane.org>
Cc: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>,
axboe-tSWWG44O7X1aa/9Udqfwiw@public.gmane.org,
linux-block-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
dm-devel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org,
cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Chris Friesen
<chris.friesen-CWA4WttNNZF54TAoqtyWWQ@public.gmane.org>,
Vivek Goyal <vgoyal-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Subject: Re: block: transfer source bio's cgroup tags to clone via bio_associate_blkcg()
Date: Mon, 14 Mar 2016 15:49:12 -0400 [thread overview]
Message-ID: <20160314194912.GA6975@redhat.com> (raw)
In-Reply-To: <56E6D95B.3030904-/eCPMmvKun9pLGFMi4vTTA@public.gmane.org>
On Mon, Mar 14 2016 at 11:31am -0400,
Nikolay Borisov <n.borisov-/eCPMmvKun9pLGFMi4vTTA@public.gmane.org> wrote:
>
>
> On 03/14/2016 05:08 PM, Nikolay Borisov wrote:
> >
> >
> > On 03/02/2016 07:56 PM, Mike Snitzer wrote:
> >> On Wed, Mar 02 2016 at 11:06P -0500,
> >> Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> >>
> >>> Hello,
> >>>
> >>> On Thu, Feb 25, 2016 at 09:53:14AM -0500, Mike Snitzer wrote:
> >>>> Right, LVM created devices are bio-based DM devices in the kernel.
> >>>> bio-based block devices do _not_ have an IO scheduler. Their underlying
> >>>> request-based device does.
> >>>
> >>> dm devices are not the actual resource source, so I don't think it'd
> >>> work too well to put io controllers on them (can't really do things
> >>> like proportional control without owning the queue).
> >>>
> >>>> I'm not well-versed on the top-level cgroup interface and how it maps to
> >>>> associated resources that are established in the kernel. But it could
> >>>> be that the configuration of blkio cgroup against a bio-based LVM device
> >>>> needs to be passed through to the underlying request-based device
> >>>> (e.g. /dev/sda4 in Chris's case)?
> >>>>
> >>>> I'm also wondering whether the latest cgroup work that Tejun has just
> >>>> finished (afaik to support buffered IO in the IO controller) will afford
> >>>> us a more meaningful reason to work to make cgroups' blkio controller
> >>>> actually work with bio-based devices like LVM's DM devices?
> >>>>
> >>>> I'm very much open to advice on how to proceed with investigating this
> >>>> integration work. Tejun, Vivek, anyone else: if you have advice on next
> >>>> steps for DM on this front _please_ yell, thanks!
> >>>
> >>> I think the only thing necessary is dm transferring bio cgroup tags to
> >>> the bio's that it ends up passing down the stack. Please take a look
> >>> at fs/btrfs/extent_io.c::btrfs_bio_clone() for an example. We
> >>> probably should introduce a wrapper for this so that each site doesn't
> >>> need to ifdef it.
> >>>
> >>> Thanks.
> >>
> >> OK, I think this should do it. Nikolay and/or others can you test this
> >> patch using blkio cgroups controller with LVM devices and report back?
> >>
> >> From: Mike Snitzer <snitzer-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> >> Date: Wed, 2 Mar 2016 12:37:39 -0500
> >> Subject: [PATCH] block: transfer source bio's cgroup tags to clone via bio_associate_blkcg()
> >>
> >> Move btrfs_bio_clone()'s support for transferring a source bio's cgroup
> >> tags to a clone into both bio_clone_bioset() and __bio_clone_fast().
> >> The former is used by btrfs (MD and blk-core also use it via bio_split).
> >> The latter is used by both DM and bcache.
> >>
> >> This should enable the blkio cgroups controller to work with all
> >> stacking bio-based block devices.
> >>
> >> Reported-by: Nikolay Borisov <kernel-6AxghH7DbtA@public.gmane.org>
> >> Suggested-by: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
> >> Signed-off-by: Mike Snitzer <snitzer-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> >> ---
> >> block/bio.c | 10 ++++++++++
> >> fs/btrfs/extent_io.c | 6 ------
> >> 2 files changed, 10 insertions(+), 6 deletions(-)
> >
> >
> > So I had a chance to test the settings here is what I got when running
> > 2 container, using LVM-thin for their root device and having applied
> > your patch:
> >
> > When the 2 containers are using the same blkio.weight values (500) I
> > get the following from running DD simultaneously on the 2 containers:
> >
> > [root@c1501 ~]# dd if=test.img of=test2.img bs=1M count=3000 oflag=direct
> > 3000+0 records in
> > 3000+0 records out
> > 3145728000 bytes (3.1 GB) copied, 165.171 s, 19.0 MB/s
> >
> > [root@c1500 ~]# dd if=test.img of=test2.img bs=1M count=3000 oflag=direct
> > 3000+0 records in
> > 3000+0 records out
> > 3145728000 bytes (3.1 GB) copied, 166.165 s, 18.9 MB/s
> >
> > Also iostat showed the 2 volumes using almost the same amount of
> > IO (around 20mb r/w). I then increase the weight for c1501 to 1000 i.e.
> > twice the bandwidth that c1500 has, so I would expect its dd to complete
> > twice as fast:
> >
> > [root@c1501 ~]# dd if=test.img of=test2.img bs=1M count=3000 oflag=direct
> > 3000+0 records in
> > 3000+0 records out
> > 3145728000 bytes (3.1 GB) copied, 150.892 s, 20.8 MB/s
> >
> >
> > [root@c1500 ~]# dd if=test.img of=test2.img bs=1M count=3000 oflag=direct
> > 3000+0 records in
> > 3000+0 records out
> > 3145728000 bytes (3.1 GB) copied, 157.167 s, 20.0 MB/s
> >
> > Now repeating the same tests but this time using the page-cache
> > (echo 3 > /proc/sys/vm/drop_caches) was executed before each test run:
> >
> > With equal weights (500):
> > [root@c1501 ~]# dd if=test.img of=test2.img bs=1M count=3000
> > 3000+0 records in
> > 3000+0 records out
> > 3145728000 bytes (3.1 GB) copied, 114.923 s, 27.4 MB/s
> >
> > [root@c1500 ~]# dd if=test.img of=test2.img bs=1M count=3000
> > 3000+0 records in
> > 3000+0 records out
> > 3145728000 bytes (3.1 GB) copied, 120.245 s, 26.2 MB/s
> >
> > With (c1501's weight equal to twice that of c1500 (1000)):
> >
> > [root@c1501 ~]# dd if=test.img of=test2.img bs=1M count=3000
> > 3000+0 records in
> > 3000+0 records out
> > 3145728000 bytes (3.1 GB) copied, 99.0181 s, 31.8 MB/s
> >
> > [root@c1500 ~]# dd if=test.img of=test2.img bs=1M count=3000
> > 3000+0 records in
> > 3000+0 records out
> > 3145728000 bytes (3.1 GB) copied, 122.872 s, 25.6 MB/s
>
> And another test which makes it obvious that your patch works:
>
> [root@c1501 ~]# dd if=test.img of=test2.img bs=1M count=6000
> 6000+0 records in
> 6000+0 records out
> 6291456000 bytes (6.3 GB) copied, 210.466 s, 29.9 MB/s
>
> [root@c1500 ~]# dd if=test.img of=test2.img bs=1M count=3000
> 3000+0 records in
> 3000+0 records out
> 3145728000 bytes (3.1 GB) copied, 201.118 s, 15.6 MB/s
>
>
> So a file that is twice the size of another one (6vs3 g) is copied for
> almost the same amount of time with 2x the bandwidth.
Great.
Jens, can you pick up the patch in question ("[PATCH] block: transfer
source bio's cgroup tags to clone via bio_associate_blkcg()") that I
posted in this thread?
next prev parent reply other threads:[~2016-03-14 19:49 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-24 18:12 blkio cgroups controller doesn't work with LVM? Chris Friesen
[not found] ` <56CDF283.9010802-CWA4WttNNZF54TAoqtyWWQ@public.gmane.org>
2016-02-25 7:48 ` Nikolay Borisov
[not found] ` <56CEB1BC.4000005-6AxghH7DbtA@public.gmane.org>
2016-02-25 14:53 ` Mike Snitzer
[not found] ` <20160225145314.GA20699-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2016-02-25 15:15 ` Chris Friesen
2016-02-26 16:42 ` [dm-devel] " Vivek Goyal
[not found] ` <20160226164228.GA24711-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2016-02-26 16:45 ` Vivek Goyal
2016-03-02 16:06 ` Tejun Heo
[not found] ` <20160302160649.GB29826-qYNAdHglDFBN0TnZuCh8vA@public.gmane.org>
2016-03-02 17:56 ` [PATCH] block: transfer source bio's cgroup tags to clone via bio_associate_blkcg() (was: Re: blkio cgroups controller doesn't work with LVM?) Mike Snitzer
[not found] ` <20160302175656.GA59991-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2016-03-02 18:03 ` Nikolay Borisov
[not found] ` <CAJFSNy6hni1-NWDs0z=Hq223=DfcjsNPoAb7GRAGEPCUXh4Q9w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-03-02 18:05 ` Mike Snitzer
2016-03-02 19:18 ` [PATCH] " Vivek Goyal
2016-03-02 19:59 ` Nikolay Borisov
2016-03-02 20:10 ` Vivek Goyal
2016-03-02 20:19 ` Nikolay Borisov
[not found] ` <CAJFSNy6MUGr8E3RNw6hFiskcaG4m8EGdqMkQXVh1LGq-yZCjBg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2016-03-02 20:45 ` Vivek Goyal
[not found] ` <20160302201016.GE3476-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2016-03-02 20:34 ` [PATCH] block: transfer source bio's cgroup tags to clone via bio_associate_blkcg() Chris Friesen
[not found] ` <56D74E6A.9050708-CWA4WttNNZF54TAoqtyWWQ@public.gmane.org>
2016-03-02 21:04 ` Vivek Goyal
[not found] ` <20160302210405.GG3476-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2016-03-02 21:19 ` Vivek Goyal
2016-03-14 15:08 ` Nikolay Borisov
[not found] ` <56E6D3D3.4070104-6AxghH7DbtA@public.gmane.org>
2016-03-14 15:31 ` Nikolay Borisov
[not found] ` <56E6D95B.3030904-/eCPMmvKun9pLGFMi4vTTA@public.gmane.org>
2016-03-14 19:49 ` Mike Snitzer [this message]
[not found] ` <20160314194912.GA6975-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2016-03-14 22:08 ` Nikolay Borisov
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=20160314194912.GA6975@redhat.com \
--to=snitzer-h+wxahxf7alqt0dzr+alfa@public.gmane.org \
--cc=axboe-tSWWG44O7X1aa/9Udqfwiw@public.gmane.org \
--cc=cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=chris.friesen-CWA4WttNNZF54TAoqtyWWQ@public.gmane.org \
--cc=dm-devel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
--cc=linux-block-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=n.borisov-/eCPMmvKun9pLGFMi4vTTA@public.gmane.org \
--cc=tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org \
--cc=vgoyal-H+wXaHxf7aLQT0dZR+AlfA@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.