From: Jens Axboe <axboe@suse.de>
To: Matt Helsley <matthltc@us.ibm.com>
Cc: Con Kolivas <kernel@kolivas.org>, Marc Perkel <marc@perkel.com>,
LKML <linux-kernel@vger.kernel.org>,
Shailabh Nagar <nagar@watson.ibm.com>
Subject: Re: Making nice niser for system hogging programs
Date: Wed, 5 Oct 2005 12:02:30 +0200 [thread overview]
Message-ID: <20051005100229.GH3511@suse.de> (raw)
In-Reply-To: <1128461162.12346.2609.camel@stark>
On Tue, Oct 04 2005, Matt Helsley wrote:
> On Sun, 2005-10-02 at 13:07 +1000, Con Kolivas wrote:
> > On Sun, 2 Oct 2005 12:26, Marc Perkel wrote:
> > > Just a thought -----
> > >
> > > Programs like cp -a /bigdir /backup and rsync usually bring the server
> > > to a crawl no matter how much "nice" you put on them. Is there any way
> > > to make "nice" smarter in that it limits io as well as processor usage?
> > > If cp and rsyne ran a little slower IO wise then everything else could
> > > run too.
> >
> > The latest cfq io scheduler supports io nice levels. By default it links the
> > io nice levels to the cpu nice levels so if you use cfq and set your file
> > commands nice 19 they will use as little io priority as possible. Note this
> > only works on the read side but that makes a dramatic difference already.
> >
> > Cheers
> > Con
>
> If you want a way to assign io priorities without relying on process
> inheritance and (re)nice you might find CKRM, with it's cfq-based IO
> controller, useful.
>
> Basically you create a set of classes that group tasks and give an
> appropriate share of IO performance to tasks in that class. As processes
> get created CKRM will assign tasks to the IO classes based on a set of
> rules. You can run commands like:
>
> mkdir /rcfs/taskclass/makin_copies
> echo 'res=io,guarantee=20' > /rcfs/taskclass/makin_copies/shares
> echo 'path=/usr/bin/rsync,class=makin_copies' > /rcfs/ce/rsync_rule
> echo 'path=/bin/cp,class=makin_copies' > /rcfs/ce/cp_rule
>
> to set this up. This should make CKRM useful for those unwilling to
> become full-time administrators just to run their own desktops.
Has the CKRM io controller been updated to 2.6.13 level CFQ, or is it
still using the very basic per-request based io sharing?
--
Jens Axboe
prev parent reply other threads:[~2005-10-05 10:02 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-10-02 2:26 Making nice niser for system hogging programs Marc Perkel
2005-10-02 3:07 ` Con Kolivas
2005-10-02 3:18 ` Marc Perkel
2005-10-02 3:38 ` Con Kolivas
2005-10-04 21:26 ` Matt Helsley
2005-10-05 10:02 ` Jens Axboe [this message]
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=20051005100229.GH3511@suse.de \
--to=axboe@suse.de \
--cc=kernel@kolivas.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marc@perkel.com \
--cc=matthltc@us.ibm.com \
--cc=nagar@watson.ibm.com \
/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