All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@osdl.org>
To: Neil Brown <neilb@suse.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH - RFC] allow setting vm_dirty below 1% for large memory machines
Date: Tue, 9 Jan 2007 19:41:01 -0800	[thread overview]
Message-ID: <20070109194101.c8a1beaa.akpm@osdl.org> (raw)
In-Reply-To: <17828.23967.419596.669927@notabene.brown>

On Wed, 10 Jan 2007 14:29:35 +1100
Neil Brown <neilb@suse.de> wrote:

> > 
> > It would be better if we can avoid creating the second global variable.  Is
> > it not possible to remove dirty_ratio?  Make everything work off
> > vm_dirty_kb and do arithmetricks at the /proc/sys/vm/dirty_ratio interface?
> 
> Uhmmm... not sure what you are thinking.
> I guess we could teach vm.dirty_ratio to take a floating point number
> (but does sysctl understand that?) so we could set it to 0.01 or
> similar, but that is missing the point in a way.  We don't really want
> to set a small ratio.  We want to set a small maximum number.

I mean remove the kernel-internal dirty_ratio variable and use
/proc/sys/vm/dirty_ratio as an accessor to `long vm_dirty_kb', with
appropriate conversions when /proc/sys/vm/dirty_ratio is written to and
read from.

> It could make lots of sense to have two numbers.  A ratio that wins on
> a small memory machine and a fixed number that wins on a large memory
> machine.  Different trade offs are more significant in the different
> cases.

hm.

> > 
> > We should perform the same conversion to dirty_background_ratio, I suspect.
> > 
> 
> I didn't add a fixed limit for dirty_background_ratio as it seemed
> reasonable to assume that (dirty_background_ratio / dirty_ratio) was a
> meaningful value, and just multiplied the final 'dirty' figure by this
> ration to get the 'background' figure.

Sounds complex.  Better, I think, to create (and recommend) vm_dirty_kb and
vm_dirty_background_kb and deprecate the old knobs.

> > And these guys should be `long', not `int'.  Otherwise things will go
> > pearshaped at 2 tabbybytes.
> 
> I don't think so.  You would need to have blindingly fast storage
> before there would be any interest in vm_dirty_kb getting anything
> close to t*bytes.  But I guess we can make it 'unsigned long' if it
> helps.
> 

A 16TB machine would overflow that int by default.

  reply	other threads:[~2007-01-10  3:41 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-09  8:57 [PATCH - RFC] allow setting vm_dirty below 1% for large memory machines Neil Brown
2007-01-09 10:10 ` Andrew Morton
2007-01-10  3:04   ` Neil Brown
2007-01-10  3:29   ` Neil Brown
2007-01-10  3:41     ` Andrew Morton [this message]
2007-01-11 11:04 ` dean gaudet
2007-01-11 20:21   ` Andrew Morton
2007-01-11 22:35     ` dean gaudet
2007-01-11 22:48       ` Andrew Morton
2007-03-07 10:23         ` Leroy van Logchem

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=20070109194101.c8a1beaa.akpm@osdl.org \
    --to=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=neilb@suse.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 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.