public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Brice Figureau <brice+lklm@daysofwonder.com>
To: Leroy van Logchem <leroy.vanlogchem@wldelft.nl>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [RFC][PATCH 0/3] VM throttling: avoid blocking occasional	writers
Date: Fri, 02 Mar 2007 17:04:36 +0100	[thread overview]
Message-ID: <1172851477.9640.26.camel@localhost.localdomain> (raw)
In-Reply-To: <loom.20070302T140036-942@post.gmane.org>

Hi,

On Fri, 2007-03-02 at 13:06 +0000, Leroy van Logchem wrote:
> > I'm sorry to piggy-back this thread.
> > 
> > Could it be what I'm experiencing in the following bugzilla report:
> > http://bugzilla.kernel.org/show_bug.cgi?id=7372
> > 
> > As I explained in the report, I see this issue only since 2.6.18.
> > So if your concern is related to mine, what could have changed between
> > 2.6.17 and 2.6.18 related to this?
> 
> I don't think it's 2.6.x related, it's been under the sheets from start.

Maybe. Still the issue has been aggravated between 2.6.17 and 2.6.18.
Right now (running 2.6.17.13) I can backup and do whatever I want, even
with high memory pressure because of mysql (which is consumming right
now about 3.8GB of 4GB).

Under 2.6.18 and later it is simply impossible to perform that (except
with the dd directIO trick).
This makes me think that something else has joined the party on
2.6.18...

> Related to your problem in the 7372 bug:
> 
> Pages are kept in memory for re-use, which is fast and fine except for:
> 1) data without re-use value or even single use
> 2) applications _do not_ advise the kernel how to cache pages related
>    to there self generated i/o. POSIX does provide mechanisms to
>    properly do so. But the kernel should help these poor apps.
>
> To minimize your MySQL backup cp(1) problem, try this workaround:
> 
> cat ./cp_direct.sh 
> #!/bin/sh
> dd if=$1 of=$2 bs=1M iflag=direct oflag=direct

Yes, I already did this, and it helped, see:
http://bugzilla.kernel.org/show_bug.cgi?id=7372#c16

> Combine this with [/etc/sysctl.conf]:
> 
> vm.vfs_cache_pressure = 1
> vm.dirty_ratio = 2
> vm.dirty_background_ratio = 1
> 
> This should reduce both the stress on the vm and response latency during
> interactive work.

I'll test the vfs_cache_pressure (I was already using those dirty_*
settings) whenever I'll reboot the server to 2.6.20.

Please CC: me on list replies as I'm not subscribed to the list.

Thanks for the tips.
Regards
-- 
Brice Figureau <brice+lklm@daysofwonder.com>


  reply	other threads:[~2007-03-02 16:04 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-23 12:03 [RFC][PATCH 0/3] VM throttling: avoid blocking occasional writers Tomoki Sekiyama
2007-02-24  4:46 ` KAMEZAWA Hiroyuki
2007-02-27  0:50   ` Tomoki Sekiyama
2007-02-27  1:39     ` KAMEZAWA Hiroyuki
2007-03-02  1:26       ` Tomoki Sekiyama
2007-02-24 13:15 ` Nikita Danilov
2007-02-27  0:52   ` Tomoki Sekiyama
2007-03-01 12:47     ` Leroy van Logchem
2007-03-02  9:16       ` Brice Figureau
2007-03-02 13:06         ` Leroy van Logchem
2007-03-02 16:04           ` Brice Figureau [this message]
2007-03-07 13:53       ` Yuji Kakutani

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=1172851477.9640.26.camel@localhost.localdomain \
    --to=brice+lklm@daysofwonder.com \
    --cc=leroy.vanlogchem@wldelft.nl \
    --cc=linux-kernel@vger.kernel.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