From: Anthony Wesley <awesley@acquerra.com.au>
To: nate.diller@gmail.com
Cc: Roger Heflin <rheflin@atipa.com>, linux-kernel@vger.kernel.org
Subject: Re: kernel 2.6.13 buffer strangeness
Date: Sat, 10 Sep 2005 10:50:11 +1000 [thread overview]
Message-ID: <43222DC3.9080609@acquerra.com.au> (raw)
In-Reply-To: <5c49b0ed05090914394dba42bf@mail.gmail.com>
Based on a better understanding of dirty_ratio and dirty_background ratio (thanks Nate) I just tried
the following test:
dirty_ratio set to 95
dirty_background_ratio set to 1
>From Nate's description of these parameters, this should mean that the disk writes
start almost immediately, and the kernel will allow 95% of RAM to become dirty before
applying the throttle.
Ok, so with 25Mbytes/s coming in, and 17Mbytes/sec going out to disk, the dirty pages should be growing
at 7Mbytes/sec. With these parameters set as above I should see about 3 minutes of full speed
video before the throttle is applied since I have about 1.3Gb of RAM free for buffering..
*But* when I try this experiment I hit the throttle after only 65 seconds - an improvement to
be sure, but still a long way short of the 180 seconds that it ought to take.
Part of the test works as expected - the disk writes begin almost immediately due to the low
value for dirty_background_ratio, but the rest is a mystery.
It really looks as if the pages aren't being marked as clean fast enough after they're written.
How else can it take only 70 seconds to reach 95% dirty when I have 1.3Gb of available RAM and data coming in at 25MBytes/sec and out at 17MBytes/sec? It doesn't make any sense...
regards, Anthony
Nate Diller wrote:
> yes, on 2.6 there are two tunables which are important here.
> dirty_background_ratio is the threshold where the kernel will begin
> flushing dirty buffers, so it should change how soon the disk becomes
> active. dirty_ratio changes when the write-throttling code kicks in,
> which is what Anthony is seeing. The purpose of the write throttling
> code is to limit the dirtying process to disk bandwidth, so that is a
> Feature. Anthony, try *increasing* dirty_ratio, you can go up to 100,
> but you could trigger an OOM if you let it get too high, so maybe try
> setting it at 85 or so. This should effectively disable the write
> throttling and give you the bandwidth you want.
>
> NATE
--
Anthony Wesley
Director and IT/Network Consultant
Smart Networks Pty Ltd
Acquerra Pty Ltd
Anthony.Wesley@acquerra.com.au
Phone: (02) 62595404 or 0419409836
next prev parent reply other threads:[~2005-09-10 0:46 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-09-09 9:11 kernel 2.6.13 buffer strangeness Anthony Wesley
2005-09-09 15:09 ` Roger Heflin
2005-09-09 21:39 ` Nate Diller
2005-09-10 0:16 ` Anthony Wesley
2005-09-10 0:35 ` Nate Diller
2005-09-10 1:07 ` Anthony Wesley
2005-09-10 1:47 ` Nate Diller
2005-09-10 2:23 ` Anthony Wesley
[not found] ` <5c49b0ed05090922021b8f8112@mail.gmail.com>
2005-09-10 5:32 ` Anthony Wesley
2005-09-10 6:02 ` kernel 2.6.13 buffer strangeness - FIXED Anthony Wesley
2005-09-10 10:23 ` kernel 2.6.13 buffer strangeness - ext2/3/reiser4/xfs comparison Anthony Wesley
2005-09-10 11:42 ` Andrew Morton
2005-09-10 11:56 ` Anthony Wesley
2005-09-10 0:50 ` Anthony Wesley [this message]
2005-09-10 5:41 ` kernel 2.6.13 buffer strangeness Andrew Morton
-- strict thread matches above, loose matches on Subject: below --
2005-09-09 8:14 Anthony Wesley
2005-09-09 8:24 ` David Lang
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=43222DC3.9080609@acquerra.com.au \
--to=awesley@acquerra.com.au \
--cc=linux-kernel@vger.kernel.org \
--cc=nate.diller@gmail.com \
--cc=rheflin@atipa.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.