public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Martin Knoblauch <knobi@knobisoft.de>
To: linux-kernel@vger.kernel.org
Cc: spam trap <spamtrap@knobisoft.de>
Subject: Re: Understanding I/O behaviour
Date: Fri, 6 Jul 2007 04:03:41 -0700 (PDT)	[thread overview]
Message-ID: <543242.2447.qm@web32607.mail.mud.yahoo.com> (raw)

Martin Knoblauch wrote:
>--- Robert Hancock <hancockr@xxxxxxx> wrote:
>
>>
>> Try playing with reducing /proc/sys/vm/dirty_ratio and see how that
>> helps. This workload will fill up memory with dirty data very
>> quickly,
>> and it seems like system responsiveness often goes down the toilet
>> when
>> this happens and the system is going crazy trying to write it all
>> out.
>>
>
>Definitely the "going crazy" part is the worst problem I see with 2.6
>based kernels (late 2.4 was really better in this corner case).
>
>I am just now playing with dirty_ratio. Anybody knows what the lower
>limit is? "0" seems acceptabel, but does it actually imply "write out
>immediatelly"?
>
>Another problem, the VM parameters are not really well documented in
>their behaviour and interdependence.

 Lowering dirty_ration just leads to more imbalanced write-speed for
the three dd's. Even when lowering the number to 0, the hich load
stays.

 Now, on another experiment I mounted the FS with "sync". And now the
load stays below/around 3. No more "pdflush" daemons going wild. And
the responsiveness is good, with no drops.

 My question is now: is there a parameter that one can use to force
immediate writeout for every process. This may hurt overall performance
of the system, but might really help my situation. Setting dirty_ratio
to 0 does not seem to do it.

Cheers
Martin

------------------------------------------------------
Martin Knoblauch
email: k n o b i AT knobisoft DOT de
www:   http://www.knobisoft.de

             reply	other threads:[~2007-07-06 11:03 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-06 11:03 Martin Knoblauch [this message]
  -- strict thread matches above, loose matches on Subject: below --
2007-07-06 14:25 Understanding I/O behaviour Daniel J Blueman
2007-07-06 15:17 ` Martin Knoblauch
2007-07-06 15:44   ` Daniel J Blueman
2007-07-06 12:44 Martin Knoblauch
2007-07-06 10:18 Martin Knoblauch
     [not found] <fa.gAvf+r9fiPwNwNVqahYy5u1/Is0@ifi.uio.no>
2007-07-05 23:47 ` Robert Hancock
2007-07-05 23:53   ` Jesper Juhl
2007-07-06  7:54     ` Martin Knoblauch
2007-07-06 10:15       ` Brice Figureau
2007-07-06 10:11   ` Martin Knoblauch
2007-07-07 13:23     ` Leroy van Logchem
2007-07-05 15:40 Martin Knoblauch
2007-07-05 18:15 ` Andrew Lyon
2007-07-05 20:22 ` Jesper Juhl
2007-07-08 21:28   ` Jesper Juhl
2007-07-09  8:47     ` Martin Knoblauch

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=543242.2447.qm@web32607.mail.mud.yahoo.com \
    --to=knobi@knobisoft.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=spamtrap@knobisoft.de \
    /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