From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Andrew Morton <akpm@osdl.org>
Cc: linux-mm@kvack.org
Subject: Re: [PATCH] 3/4: writeout watermarks
Date: Fri, 06 Aug 2004 16:13:35 +1000 [thread overview]
Message-ID: <4113218F.5050803@yahoo.com.au> (raw)
In-Reply-To: <20040805224920.6755198d.akpm@osdl.org>
Andrew Morton wrote:
> Nick Piggin <nickpiggin@yahoo.com.au> wrote:
>
>>No, it is not that code I am worried about, you're actually doing
>> this too (disregarding the admin's wishes):
>>
>> dirty_ratio = vm_dirty_ratio;
>> if (dirty_ratio > unmapped_ratio / 2)
>> dirty_ratio = unmapped_ratio / 2;
>>
>> if (dirty_ratio < 5)
>> dirty_ratio = 5;
>>
>
>
> hm, OK, that's some "try to avoid writeback off the LRU" stuff.
>
Yep
> But you said "This ensures we should always attempt to start background
> writeout before synchronous writeout.". Does not the current code do that?
>
Basically what the above code, is scale the dirty_ratio with the
amount of unmapped pages, however it doesn't also scale the
dirty_background_ratio (it does after my patch).
So it isn't difficult to imagine this causing dirty_ratio to become
very close to dirty_background_ratio.
The crude check prevents the values from becoming exactly equal.
if (background_ratio >= dirty_ratio)
background_ratio = dirty_ratio / 2;
>
>> So if the admin wants a dirty_ratio of 40 and dirty_background_ratio of 10
>> then that's good, but I'm sure if they knew you're moving dirty_ratio to 10
>> here, they'd want something like 2 for the dirty_background_ratio.
>>
>> I contend that the ratio between these two values is more important than
>> their absolue values -- especially considering one gets twiddled here.
>
>
> Maybe true, maybe false. These things are demonstrable via testing, no?
>
>
Might be, I don't know how. Seemed straightforward (to me).
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
next prev parent reply other threads:[~2004-08-06 6:13 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-06 4:57 [PATCH] 1/4: rework alloc_pages Nick Piggin
2004-08-06 4:57 ` [PATCH] 2/4: highmem watermarks Nick Piggin
2004-08-06 5:03 ` [PATCH] 3/4: writeout watermarks Nick Piggin
2004-08-06 5:04 ` [PATCH] 4/4: incremental min aware kswapd Nick Piggin
2004-08-06 5:27 ` [PATCH] 3/4: writeout watermarks Andrew Morton
2004-08-06 5:34 ` Nick Piggin
2004-08-06 5:49 ` Andrew Morton
2004-08-06 6:13 ` Nick Piggin [this message]
2004-08-06 6:19 ` Andrew Morton
2004-08-06 6:36 ` Nick Piggin
2004-08-06 5:12 ` [PATCH] 1/4: rework alloc_pages Nick Piggin
2004-08-06 5:19 ` Andrew Morton
2004-08-06 5:29 ` Nick Piggin
2004-08-06 5:37 ` Andrew Morton
2004-08-06 6:05 ` Nick Piggin
2004-08-06 6:17 ` Andrew Morton
2004-08-06 12:01 ` Rik van Riel
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=4113218F.5050803@yahoo.com.au \
--to=nickpiggin@yahoo.com.au \
--cc=akpm@osdl.org \
--cc=linux-mm@kvack.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 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.