From: Vivek Goyal <vgoyal@redhat.com>
To: Dave Chinner <david@fromorbit.com>
Cc: Jan Kara <jack@suse.cz>, Greg Thelen <gthelen@google.com>,
James Bottomley <James.Bottomley@hansenpartnership.com>,
lsf@lists.linux-foundation.org, linux-fsdevel@vger.kernel.org,
linux kernel mailing list <linux-kernel@vger.kernel.org>
Subject: Re: cgroup IO throttling and filesystem ordered mode (Was: Re: [Lsf] IO less throttling and cgroup aware writeback (Was: Re: Preliminary Agenda and Activities for LSF))
Date: Tue, 19 Apr 2011 14:30:22 -0400 [thread overview]
Message-ID: <20110419183022.GN31712@redhat.com> (raw)
In-Reply-To: <20110419171723.GM31712@redhat.com>
On Tue, Apr 19, 2011 at 01:17:23PM -0400, Vivek Goyal wrote:
> On Tue, Apr 19, 2011 at 10:30:22AM -0400, Vivek Goyal wrote:
>
> [..]
> > >
> > > In XFS, you could probably do this at the transaction reservation
> > > stage where log space is reserved. We know everything about the
> > > transaction at this point in time, and we throttle here already when
> > > the journal is full. Adding cgroup transaction limits to this point
> > > would be the place to do it, but the control parameter for it would
> > > be very XFS specific (i.e. number of transactions/s). Concurrency is
> > > not an issue - the XFS transaction subsystem is only limited in
> > > concurrency by the space available in the journal for reservations
> > > (hundred to thousands of concurrent transactions).
> >
> > Instead of transaction per second, can we implement some kind of upper
> > limit of pending transactions per cgroup. And that limit does not have
> > to be user tunable to begin with. The effective transactions/sec rate
> > will automatically be determined by IO throttling rate of the cgroup
> > at the end nodes.
> >
> > I think effectively what we need is that the notion of parallel
> > transactions so that transactions of one cgroup can make progress
> > independent of transactions of other cgroup. So if a process does
> > an fsync and it is throttled then it should block transaction of
> > only that cgroup and not other cgroups.
> >
> > You mentioned that concurrency is not an issue in XFS and hundreds of
> > thousands of concurrent trasactions can progress depending on log space
> > available. If that's the case, I think to begin with we might not have
> > to do anything at all. Processes can still get blocked but as long as
> > we have enough log space, this might not be a frequent event. I will
> > do some testing with XFS and see can I livelock the system with very
> > low IO limits.
>
> Wow, XFS seems to be doing pretty good here. I created a group of
> 1 bytes/sec limit and wrote few bytes in a file and write quit it (vim).
> That led to an fsync and process got blocked. From a different cgroup, in the
> same directory I seem to be able to do all other regular operations like ls,
> opening a new file, editing it etc.
>
> ext4 will lockup immediately. So concurrent transactions do seem to work in
> XFS.
Well, I used tedso's fsync tester test case which wrote a file of 1MB
and then did fsync. I launched this test case in two cgroups. One is
throttled and other is not. Looks like unthrottled one gets blocked
somewhere and can't make progress. So there are dependencies somewhere
even with XFS.
Thanks
Vivek
>
> Thanks
> Vivek
next prev parent reply other threads:[~2011-04-19 18:30 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20110401214947.GE6957@dastard>
[not found] ` <20110405131359.GA14239@redhat.com>
[not found] ` <20110405225639.GB31057@dastard>
[not found] ` <20110406153715.GA18777@redhat.com>
[not found] ` <20110406235039.GL31057@dastard>
[not found] ` <20110407175537.GD27778@redhat.com>
[not found] ` <20110411013630.GM30279@dastard>
[not found] ` <20110415210750.GC28323@redhat.com>
[not found] ` <20110416030602.GA26191@redhat.com>
[not found] ` <20110418215844.GA15428@quack.suse.cz>
2011-04-18 22:51 ` cgroup IO throttling and filesystem ordered mode (Was: Re: [Lsf] IO less throttling and cgroup aware writeback (Was: Re: Preliminary Agenda and Activities for LSF)) Vivek Goyal
2011-04-19 0:33 ` Dave Chinner
2011-04-19 14:30 ` Vivek Goyal
2011-04-19 14:45 ` Jan Kara
2011-04-19 17:17 ` Vivek Goyal
2011-04-19 18:30 ` Vivek Goyal [this message]
2011-04-21 0:32 ` Dave Chinner
2011-04-21 0:29 ` Dave Chinner
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=20110419183022.GN31712@redhat.com \
--to=vgoyal@redhat.com \
--cc=James.Bottomley@hansenpartnership.com \
--cc=david@fromorbit.com \
--cc=gthelen@google.com \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lsf@lists.linux-foundation.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox