From: Andrew Morton <akpm@osdl.org>
To: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
Cc: nickpiggin@yahoo.com.au, nikita@clusterfs.com,
Linux-Kernel@vger.kernel.org, AKPM@osdl.org, linux-mm@kvack.org
Subject: Re: [PATCH]: 1/4 batch mark_page_accessed()
Date: Tue, 30 Nov 2004 17:33:23 -0800 [thread overview]
Message-ID: <20041130173323.0b3ac83d.akpm@osdl.org> (raw)
In-Reply-To: <20041130162956.GA3047@dmt.cyclades>
Marcelo Tosatti <marcelo.tosatti@cyclades.com> wrote:
>
> Because the ordering of LRU pages should be enhanced in respect to locality,
> with the mark_page_accessed batching you group together tasks accessed pages
> and move them at once to the active list.
>
> You maintain better locality ordering, while decreasing the precision of aging/
> temporal locality.
>
> Which should enhance disk writeout performance.
I'll buy that explanation. Although I'm a bit sceptical that it is
measurable.
Was that particular workload actually performing significant amounts of
writeout in vmscan.c? (We should have direct+kswapd counters for that, but
we don't. /proc/vmstat:pgrotated will give us an idea).
> On the other hand, without batching you mix the locality up in LRU - the LRU becomes
> more precise in terms of "LRU aging", but less ordered in terms of sequential
> access pattern.
>
> The disk IO intensive reaim has very significant gain from the batching, its
> probably due to the enhanced LRU ordering (what Nikita says).
>
> The slowdown is probably due to the additional atomic_inc by page_cache_get().
>
> Is there no way to avoid such page_cache_get there (and in lru_cache_add also)?
Not really. The page is only in the pagevec at that time - if someone does
a put_page() on it the page will be freed for real, and will then be
spilled onto the LRU. Messy.
WARNING: multiple messages have this Message-ID (diff)
From: Andrew Morton <akpm@osdl.org>
To: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
Cc: nickpiggin@yahoo.com.au, nikita@clusterfs.com,
Linux-Kernel@vger.kernel.org, AKPM@osdl.org, linux-mm@kvack.org
Subject: Re: [PATCH]: 1/4 batch mark_page_accessed()
Date: Tue, 30 Nov 2004 17:33:23 -0800 [thread overview]
Message-ID: <20041130173323.0b3ac83d.akpm@osdl.org> (raw)
In-Reply-To: <20041130162956.GA3047@dmt.cyclades>
Marcelo Tosatti <marcelo.tosatti@cyclades.com> wrote:
>
> Because the ordering of LRU pages should be enhanced in respect to locality,
> with the mark_page_accessed batching you group together tasks accessed pages
> and move them at once to the active list.
>
> You maintain better locality ordering, while decreasing the precision of aging/
> temporal locality.
>
> Which should enhance disk writeout performance.
I'll buy that explanation. Although I'm a bit sceptical that it is
measurable.
Was that particular workload actually performing significant amounts of
writeout in vmscan.c? (We should have direct+kswapd counters for that, but
we don't. /proc/vmstat:pgrotated will give us an idea).
> On the other hand, without batching you mix the locality up in LRU - the LRU becomes
> more precise in terms of "LRU aging", but less ordered in terms of sequential
> access pattern.
>
> The disk IO intensive reaim has very significant gain from the batching, its
> probably due to the enhanced LRU ordering (what Nikita says).
>
> The slowdown is probably due to the additional atomic_inc by page_cache_get().
>
> Is there no way to avoid such page_cache_get there (and in lru_cache_add also)?
Not really. The page is only in the pagevec at that time - if someone does
a put_page() on it the page will be freed for real, and will then be
spilled onto the LRU. Messy.
--
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-12-01 1:35 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-11-21 15:44 [PATCH]: 1/4 batch mark_page_accessed() Nikita Danilov
2004-11-21 15:44 ` Nikita Danilov
2004-11-21 21:12 ` Andrew Morton
2004-11-21 21:12 ` Andrew Morton
2004-11-24 10:40 ` Marcelo Tosatti
2004-11-24 10:40 ` Marcelo Tosatti
2004-11-24 16:32 ` Marcelo Tosatti
2004-11-24 16:32 ` Marcelo Tosatti
2004-11-24 21:53 ` Nikita Danilov
2004-11-24 21:53 ` Nikita Danilov
2004-11-26 18:58 ` Marcelo Tosatti
2004-11-26 18:58 ` Marcelo Tosatti
2004-11-27 0:37 ` Nick Piggin
2004-11-27 0:37 ` Nick Piggin
2004-11-30 16:29 ` Marcelo Tosatti
2004-11-30 16:29 ` Marcelo Tosatti
2004-12-01 1:33 ` Andrew Morton [this message]
2004-12-01 1:33 ` Andrew Morton
2004-11-30 22:57 ` Marcelo Tosatti
2004-11-30 22:57 ` Marcelo Tosatti
2004-12-01 12:23 ` Nikita Danilov
2004-12-01 12:23 ` Nikita Danilov
2004-12-01 18:58 ` Marcelo Tosatti
2004-12-01 18:58 ` Marcelo Tosatti
2004-12-02 1:59 ` Andrew Morton
2004-12-02 1:59 ` Andrew Morton
2004-11-27 10:41 ` Nikita Danilov
2004-11-27 10:41 ` Nikita Danilov
2004-11-27 8:19 ` Marcelo Tosatti
2004-11-27 8:19 ` Marcelo Tosatti
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=20041130173323.0b3ac83d.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=Linux-Kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=marcelo.tosatti@cyclades.com \
--cc=nickpiggin@yahoo.com.au \
--cc=nikita@clusterfs.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.