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 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.