From: Matthew Wilcox <matthew@wil.cx>
To: David Howells <dhowells@redhat.com>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
linux-fsdevel@vger.kernel.org
Subject: Re: [RESEND][PATCH 5/6] Provide a filesystem-specific sync'able page bit
Date: Thu, 14 Oct 2004 20:44:21 +0100 [thread overview]
Message-ID: <20041014194421.GU16153@parcelfarce.linux.theplanet.co.uk> (raw)
In-Reply-To: <24461.1097780707@redhat.com>
On Thu, Oct 14, 2004 at 08:05:07PM +0100, David Howells wrote:
> #define PG_highmem 8
> +#define PG_fs_misc 9 /* Filesystem specific bit */
> #define PG_checked 9 /* kill me in 2.5.<early>. */
> #define PG_arch_1 10
> #define PG_reserved 11
> @@ -315,4 +316,13 @@ static inline void set_page_writeback(st
> test_set_page_writeback(page);
> }
>
> +/*
> + * Filesystem-specific page bit testing
> + */
> +#define PageFsMisc(page) test_bit(PG_fs_misc, &(page)->flags)
> +#define SetPageFsMisc(page) set_bit(PG_fs_misc, &(page)->flags)
> +#define TestSetPageFsMisc(page) test_and_set_bit(PG_fs_misc, &(page)->flags)
> +#define ClearPageFsMisc(page) clear_bit(PG_fs_misc, &(page)->flags)
> +#define TestClearPageFsMisc(page) test_and_clear_bit(PG_fs_misc, &(page)->flags)
> +
> #endif /* PAGE_FLAGS_H */
That's not really enough documentation. Who sets this flag? Who clears this
flag? Currently, mm/page_alloc.c clears this flag:
./mm/page_alloc.c: 1 << PG_checked | 1 << PG_mappedtodisk);
which probably wouldn't be noticed by someone grepping for uses.
If you're going to not kill this flag, at least rename it so we don't
have two defines for the same bit.
The other 'misc bit' has documentation of the form:
* PG_arch_1 is an architecture specific page state bit. The generic code
* guarantees that this bit is cleared for a page when it first is entered into
* the page cache.
which really ought to at least mention Documentation/cachetlb.txt
--
"Next the statesmen will invent cheap lies, putting the blame upon
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince
himself that the war is just, and will thank God for the better sleep
he enjoys after this process of grotesque self-deception." -- Mark Twain
--
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-10-14 19:44 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-14 19:05 David Howells
2004-10-14 19:44 ` Matthew Wilcox [this message]
2004-10-15 7:29 ` Martin Waitz
2004-10-15 15:14 ` David Howells
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=20041014194421.GU16153@parcelfarce.linux.theplanet.co.uk \
--to=matthew@wil.cx \
--cc=dhowells@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox