From: "Nate Diller" <nate.diller@gmail.com>
To: "Christoph Lameter" <clameter@sgi.com>
Cc: "Arjan van de Ven" <arjan@infradead.org>,
"Andrew Morton" <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org,
"Nick Piggin" <nickpiggin@yahoo.com.au>,
"KAMEZAWA Hiroyuki" <kamezawa.hiroyu@jp.fujitsu.com>,
"Rik van Riel" <riel@redhat.com>
Subject: Re: [RFC] Tracking mlocked pages and moving them off the LRU
Date: Tue, 6 Feb 2007 14:05:44 -0800 [thread overview]
Message-ID: <5c49b0ed0702061405u1c5e58a6n4e214f65987ab8d3@mail.gmail.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0702042236250.6748@schroedinger.engr.sgi.com>
On 2/4/07, Christoph Lameter <clameter@sgi.com> wrote:
> On Sun, 4 Feb 2007, Arjan van de Ven wrote:
>
> >
> > > Exclusion or inclusion of NR_MLOCK number is straightforward for the dirty
> > > ratio calcuations. global_page_state(NR_MLOCK) f.e. would get us totals on
> > > mlocked pages per zone. node_page_state(NR_MLOCK) gives a node specific
> > > number of mlocked pages. The nice thing about ZVCs is that it allows
> > > easy access to counts on different levels.
> >
> > however... mlocked pages still can be dirty, and want to be written back
> > at some point ;)
>
> Yes that is why we need to add them to the count of total pages.
>
> > I can see the point of doing dirty ratio as percentage of the LRU size,
> > but in that case you don't need to track NR_MLOCK, only the total LRU
> > size. (And yes it'll be sometimes optimistic because not all mlock'd
> > pages are moved off the lru yet, but I doubt you'll have that as a
> > problem in practice)
>
> The dirty ratio with the ZVCS would be
>
> NR_DIRTY + NR_UNSTABLE_NFS
> /
> NR_FREE_PAGES + NR_INACTIVE + NR_ACTIVE + NR_MLOCK
I don't understand why you want to account mlocked pages in
dirty_ratio. of course mlocked pages *can* be dirty, but they have no
relevance in the write throttling code. the point of dirty ratio is
to guarantee that there are some number of non-dirty, non-pinned,
non-mlocked pages on the LRU, to (try to) avoid deadlocks where the
writeback path needs to allocate pages, which many filesystems like to
do. if an mlocked page is clean, there's still no way to free it up,
so it should not be treated as being on the LRU at all, for write
throttling. the ideal (IMO) dirty ratio would be
NR_DIRTY - NR_DIRTY_MLOCKED + NR_UNSTABLE_NFS
/
NR_FREE_PAGES + NR_INACTIVE + NR_ACTIVE
obviously it's kinda useless to keep an NR_DIRTY_MLOCKED counter, any
of these mlock accounting schemes could easily be modified to update
the NR_DIRTY counter so that it only reflects dirty unpinned pages,
and not mlocked ones.
is that the only place you wanted to have an accurate mocked page count?
NATE
next prev parent reply other threads:[~2007-02-06 22:05 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-03 6:20 Christoph Lameter
2007-02-03 8:53 ` Andrew Morton
2007-02-03 17:56 ` Christoph Lameter
2007-02-03 18:04 ` Arjan van de Ven
2007-02-03 18:09 ` Christoph Lameter
2007-02-03 18:55 ` Christoph Lameter
2007-02-03 19:03 ` Christoph Lameter
2007-02-04 1:22 ` Andrew Morton
2007-02-04 1:49 ` Christoph Lameter
2007-02-04 8:16 ` Arjan van de Ven
2007-02-05 6:45 ` Christoph Lameter
2007-02-06 22:05 ` Nate Diller [this message]
2007-02-07 8:02 ` Christoph Lameter
2007-02-07 18:39 ` Nate Diller
2007-02-05 7:57 ` Christoph Lameter
2007-02-05 8:39 ` Arjan van de Ven
2007-02-05 16:38 ` Matt Mackall
2007-02-05 17:34 ` Christoph Lameter
2007-02-05 19:04 ` Christoph Lameter
2007-02-05 17:33 ` Christoph Lameter
2007-02-03 22:58 ` Nigel Cunningham
2007-02-03 10:16 ` Christoph Hellwig
2007-02-03 15:35 ` Martin J. Bligh
2007-02-03 17:59 ` Christoph Lameter
2007-02-03 17:33 ` Christoph Lameter
2007-02-03 22:56 ` Nigel Cunningham
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=5c49b0ed0702061405u1c5e58a6n4e214f65987ab8d3@mail.gmail.com \
--to=nate.diller@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=arjan@infradead.org \
--cc=clameter@sgi.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=nickpiggin@yahoo.com.au \
--cc=riel@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®