From: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
To: Christoph Lameter <clameter@sgi.com>
Cc: linux-mm <linux-mm@kvack.org>
Subject: Re: [RFC] Don't set/test/wait-for radix tree tags if no capability
Date: Wed, 13 Sep 2006 18:12:39 -0400 [thread overview]
Message-ID: <1158185559.5328.82.camel@localhost> (raw)
In-Reply-To: <Pine.LNX.4.64.0609131350030.19101@schroedinger.engr.sgi.com>
On Wed, 2006-09-13 at 13:51 -0700, Christoph Lameter wrote:
> On Wed, 13 Sep 2006, Lee Schermerhorn wrote:
>
> > While debugging a problem [in the out-of-tree migration cache], I
> > noticed a lot of radix-tree tag activity for address spaces that have
> > the BDI_CAP_NO_{ACCT_DIRTY|WRITEBACK} capability flags set--effectively
> > disabling these capabilities--in their backing device. Altho'
> > functionally benign, I believe that this unnecessary overhead. Seeking
> > contrary opinions.
>
> I do not think that not wanting accounting for dirty pages means that we
> should not mark those dirty. If we do this then filesystems will
> not be able to find the dirty pags for writeout.
That's why I asked, and why I noted that maybe setting the dirty tags
should be gated by the 'No writeback' capability, rather than the "No
dirty accounting" capability. But then, maybe "no writeback" doesn't
really mean that the address space/backing device doesn't do
writeback.
The 'no writeback' capability is set for things like: configfs,
hugetlbfs, dlmfs, ramfs, cpuset, sysfs, shmem segs, swap, ... And, as I
mentioned, the 'no dirty accounting' capability happens to be set for
all file systems that set 'no writeback'. However, I agree that we
shouldn't count on this.
So, do the file systems need to writeout dirty pages for these file
systems using the radix tree tags? Just looking where the tags are
queried [radix_tree_gang_lookup_tag()], it appears that tags are only
used by "real" file systems, despite a call from pagevec_lookup_tag()
that resides in mm/swap.c. And, it appears that the 'no writeback'
capability flag will prevent writeback in some cases. Not sure if it
catches all.
If we can't gate setting the flags based on the existing capabilities,
maybe we want to define a new cap flag--e.g., BDI_CAP_NO_TAGS--for use
by file systems that don't need the tags set? Not sure it's worth it,
but could eliminate some cache pollution.
Lee
--
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:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2006-09-13 22:12 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-13 19:35 Lee Schermerhorn
2006-09-13 20:51 ` Christoph Lameter
2006-09-13 22:12 ` Lee Schermerhorn [this message]
2006-09-14 15:23 ` Hugh Dickins
2006-09-14 15:52 ` Lee Schermerhorn
2006-09-14 16:20 ` Hugh Dickins
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=1158185559.5328.82.camel@localhost \
--to=lee.schermerhorn@hp.com \
--cc=clameter@sgi.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox