From: Andrew Morton <akpm@linux-foundation.org>
To: Christoph Lameter <clameter@sgi.com>
Cc: linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, hch@lst.de,
mel@skynet.ie, wli@holomorphy.com, dgc@sgi.com,
jens.axboe@oracle.com, pbadari@gmail.com,
maximlevitsky@gmail.com, fengguang.wu@gmail.com,
wangswin@gmail.com, totty.lu@gmail.com, hugh@veritas.com,
joern@lazybastard.org
Subject: Re: [patch 01/19] Define functions for page cache handling
Date: Mon, 3 Dec 2007 14:10:20 -0800 [thread overview]
Message-ID: <20071203141020.c8119197.akpm@linux-foundation.org> (raw)
In-Reply-To: <20071130173506.366983341@sgi.com>
On Fri, 30 Nov 2007 09:34:49 -0800
Christoph Lameter <clameter@sgi.com> wrote:
> We use the macros PAGE_CACHE_SIZE PAGE_CACHE_SHIFT PAGE_CACHE_MASK
> and PAGE_CACHE_ALIGN in various places in the kernel. Many times
> common operations like calculating the offset or the index are coded
> using shifts and adds. This patch provides inline functions to
> get the calculations accomplished without having to explicitly
> shift and add constants.
>
> All functions take an address_space pointer. The address space pointer
> will be used in the future to eventually support a variable size
> page cache. Information reachable via the mapping may then determine
> page size.
>
> New function Related base page constant
> ====================================================================
> page_cache_shift(a) PAGE_CACHE_SHIFT
> page_cache_size(a) PAGE_CACHE_SIZE
> page_cache_mask(a) PAGE_CACHE_MASK
> page_cache_index(a, pos) Calculate page number from position
> page_cache_next(addr, pos) Page number of next page
> page_cache_offset(a, pos) Calculate offset into a page
> page_cache_pos(a, index, offset)
> Form position based on page number
> and an offset.
>
> This provides a basis that would allow the conversion of all page cache
> handling in the kernel and ultimately allow the removal of the PAGE_CACHE_*
> constants.
>
> ...
>
> +/*
> + * Functions that are currently setup for a fixed PAGE_SIZEd. The use of
> + * these will allow the user of largere page sizes in the future.
> + */
> +static inline int mapping_order(struct address_space *a)
> +{
> + return 0;
> +}
> +
> +static inline int page_cache_shift(struct address_space *a)
> +{
> + return PAGE_SHIFT;
> +}
> +
> +static inline unsigned int page_cache_size(struct address_space *a)
> +{
> + return PAGE_SIZE;
> +}
> +
> +static inline unsigned int page_cache_offset(struct address_space *a,
> + loff_t pos)
> +{
> + return pos & ~PAGE_MASK;
> +}
> +
> +static inline pgoff_t page_cache_index(struct address_space *a,
> + loff_t pos)
> +{
> + return pos >> page_cache_shift(a);
> +}
These will of course all work OK as they are presently implemented.
But you have callsites doing things like
page_cache_size(page_mapping(page));
which is a whole different thing. Once page_cache_size() is changed to
look inside the address_space we need to handle races against truncation
and we need to handle the address_space getting reclaimed, etc.
So I think it would be misleading to merge these changes at present - they
make it _look_ like we can have variable PAGE_CACHE_SIZE just by tweaking a
bit of core code, but we in fact cannot do that without a careful review of
all callsites and perhaps the addition of new locking and null-checking.
Now, one possible way around this is to rework all these functions so they
take only a page*, and to create (and assert) the requirement that the caller
has locked the page. That's a little bit inefficient (additional calls to
page_mapping()) but it does mean that we can now confidently change the
implementation of these functions as you intend.
And a coding nit: when you implement the out-of-line versions of these
functions you're going to stick with VFS conventions and use the identifier
`mapping' to identify the address_space*. So I think it would be better to
also call in `mapping' in these inlined stubbed functions, rather than `a'.
No?
next prev parent reply other threads:[~2007-12-03 22:12 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-11-30 17:34 [patch 00/19] Page cache: Replace PAGE_CACHE_xx with inline functions V2 Christoph Lameter
2007-11-30 17:34 ` [patch 01/19] Define functions for page cache handling Christoph Lameter
2007-12-03 22:10 ` Andrew Morton [this message]
2007-12-04 5:59 ` David Chinner
2007-12-18 20:20 ` Christoph Lameter
2007-11-30 17:34 ` [patch 02/19] Use page_cache_xxx functions in mm/filemap.c Christoph Lameter
2007-11-30 17:34 ` [patch 03/19] Use page_cache_xxx in mm/page-writeback.c Christoph Lameter
2007-11-30 17:34 ` [patch 04/19] Use page_cache_xxx in mm/truncate.c Christoph Lameter
2007-11-30 17:34 ` [patch 05/19] Use page_cache_xxx in mm/rmap.c Christoph Lameter
2007-11-30 17:34 ` [patch 06/19] Use page_cache_xxx in mm/filemap_xip.c Christoph Lameter
2007-11-30 17:34 ` [patch 07/19] Use page_cache_xxx in mm/migrate.c Christoph Lameter
2007-12-04 5:45 ` David Chinner
2007-11-30 17:34 ` [patch 08/19] Use page_cache_xxx in fs/libfs.c Christoph Lameter
2007-11-30 17:34 ` [patch 09/19] Use page_cache_xxx in fs/sync Christoph Lameter
2007-11-30 17:34 ` [patch 10/19] Use page_cache_xxx in fs/buffer.c Christoph Lameter
2007-11-30 17:34 ` [patch 11/19] Use page_cache_xxx in mm/mpage.c Christoph Lameter
2007-11-30 17:35 ` [patch 12/19] Use page_cache_xxx in mm/fadvise.c Christoph Lameter
2007-11-30 17:35 ` [patch 13/19] Use page_cache_xxx in fs/splice.c Christoph Lameter
2007-11-30 17:35 ` [patch 14/19] Use page_cache_xxx in ext2 Christoph Lameter
2007-11-30 17:35 ` [patch 15/19] Use page_cache_xxx in fs/ext3 Christoph Lameter
2007-11-30 17:35 ` [patch 16/19] Use page_cache_xxx in fs/ext4 Christoph Lameter
2007-11-30 17:35 ` [patch 17/19] Use page_cache_xxx in fs/reiserfs Christoph Lameter
2007-11-30 17:35 ` [patch 18/19] Use page_cache_xxx for fs/xfs Christoph Lameter
2007-11-30 17:35 ` [patch 19/19] Use page_cache_xxx in drivers/block/rd.c Christoph Lameter
-- strict thread matches above, loose matches on Subject: below --
2007-11-29 1:10 [patch 00/19] Page cache: Replace PAGE_CACHE_xx with inline functions Christoph Lameter
2007-11-29 1:10 ` [patch 01/19] Define functions for page cache handling Christoph Lameter
2007-11-29 3:06 ` David Chinner
2007-11-29 3:21 ` Christoph Lameter
[not found] ` <E1Ixf0M-0004lI-0Z@localhost>
2007-11-29 8:44 ` Fengguang Wu
2007-11-29 19:23 ` Christoph Lameter
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=20071203141020.c8119197.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=clameter@sgi.com \
--cc=dgc@sgi.com \
--cc=fengguang.wu@gmail.com \
--cc=hch@lst.de \
--cc=hugh@veritas.com \
--cc=jens.axboe@oracle.com \
--cc=joern@lazybastard.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=maximlevitsky@gmail.com \
--cc=mel@skynet.ie \
--cc=pbadari@gmail.com \
--cc=totty.lu@gmail.com \
--cc=wangswin@gmail.com \
--cc=wli@holomorphy.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;
as well as URLs for NNTP newsgroup(s).