[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <BANLkTimEbtY8F6bpsfhfQ770ao9Hn7Spww@mail.gmail.com>
Date: Fri, 15 Apr 2011 08:37:49 +0900
From: Minchan Kim <minchan.kim@...il.com>
To: Dan Magenheimer <dan.magenheimer@...cle.com>
Cc: chris.mason@...cle.com, viro@...iv.linux.org.uk,
akpm@...ux-foundation.org, adilger.kernel@...ger.ca, tytso@....edu,
mfasheh@...e.com, jlbec@...lplan.org, matthew@....cx,
linux-btrfs@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-fsdevel@...r.kernel.org, linux-ext4@...r.kernel.org,
ocfs2-devel@....oracle.com, linux-mm@...ck.org, hch@...radead.org,
ngupta@...are.org, jeremy@...p.org, JBeulich@...ell.com,
kurt.hackel@...cle.com, npiggin@...nel.dk,
dave.mccracken@...cle.com, riel@...hat.com, avi@...hat.com,
konrad.wilk@...cle.com, mel@....ul.ie, yinghan@...gle.com,
gthelen@...gle.com, torvalds@...ux-foundation.org
Subject: Re: [PATCH V8 4/8] mm/fs: add hooks to support cleancache
Hi Dan,
On Fri, Apr 15, 2011 at 6:17 AM, Dan Magenheimer
<dan.magenheimer@...cle.com> wrote:
> [PATCH V8 4/8] mm/fs: add hooks to support cleancache
>
> This fourth patch of eight in this cleancache series provides the
> core hooks in VFS for: initializing cleancache per filesystem;
> capturing clean pages reclaimed by page cache; attempting to get
> pages from cleancache before filesystem read; and ensuring coherency
> between pagecache, disk, and cleancache. Note that the placement
> of these hooks was stable from 2.6.18 to 2.6.38; a minor semantic
> change was required due to a patchset in 2.6.39.
>
> All hooks become no-ops if CONFIG_CLEANCACHE is unset, or become
> a check of a boolean global if CONFIG_CLEANCACHE is set but no
> cleancache "backend" has claimed cleancache_ops.
>
> Details and a FAQ can be found in Documentation/vm/cleancache.txt
>
> [v8: minchan.kim@...il.com: adapt to new remove_from_page_cache function]
> Signed-off-by: Chris Mason <chris.mason@...cle.com>
> Signed-off-by: Dan Magenheimer <dan.magenheimer@...cle.com>
> Reviewed-by: Jeremy Fitzhardinge <jeremy@...p.org>
> Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
> Cc: Andrew Morton <akpm@...ux-foundation.org>
> Cc: Al Viro <viro@...IV.linux.org.uk>
> Cc: Matthew Wilcox <matthew@....cx>
> Cc: Nick Piggin <npiggin@...nel.dk>
> Cc: Mel Gorman <mel@....ul.ie>
> Cc: Rik Van Riel <riel@...hat.com>
> Cc: Jan Beulich <JBeulich@...ell.com>
> Cc: Andreas Dilger <adilger@....com>
> Cc: Ted Ts'o <tytso@....edu>
> Cc: Mark Fasheh <mfasheh@...e.com>
> Cc: Joel Becker <joel.becker@...cle.com>
> Cc: Nitin Gupta <ngupta@...are.org>
>
> ---
>
> Diffstat:
> fs/buffer.c | 5 +++++
> fs/mpage.c | 7 +++++++
> fs/super.c | 3 +++
> mm/filemap.c | 11 +++++++++++
> mm/truncate.c | 6 ++++++
> 5 files changed, 32 insertions(+)
>
> --- linux-2.6.39-rc3/fs/super.c 2011-04-11 18:21:51.000000000 -0600
> +++ linux-2.6.39-rc3-cleancache/fs/super.c 2011-04-13 17:08:09.175853426 -0600
> @@ -31,6 +31,7 @@
> #include <linux/mutex.h>
> #include <linux/backing-dev.h>
> #include <linux/rculist_bl.h>
> +#include <linux/cleancache.h>
> #include "internal.h"
>
>
> @@ -112,6 +113,7 @@ static struct super_block *alloc_super(s
> s->s_maxbytes = MAX_NON_LFS;
> s->s_op = &default_op;
> s->s_time_gran = 1000000000;
> + s->cleancache_poolid = -1;
> }
> out:
> return s;
> @@ -177,6 +179,7 @@ void deactivate_locked_super(struct supe
> {
> struct file_system_type *fs = s->s_type;
> if (atomic_dec_and_test(&s->s_active)) {
> + cleancache_flush_fs(s);
> fs->kill_sb(s);
> /*
> * We need to call rcu_barrier so all the delayed rcu free
> --- linux-2.6.39-rc3/fs/buffer.c 2011-04-11 18:21:51.000000000 -0600
> +++ linux-2.6.39-rc3-cleancache/fs/buffer.c 2011-04-13 17:07:24.700917174 -0600
> @@ -41,6 +41,7 @@
> #include <linux/bitops.h>
> #include <linux/mpage.h>
> #include <linux/bit_spinlock.h>
> +#include <linux/cleancache.h>
>
> static int fsync_buffers_list(spinlock_t *lock, struct list_head *list);
>
> @@ -269,6 +270,10 @@ void invalidate_bdev(struct block_device
> invalidate_bh_lrus();
> lru_add_drain_all(); /* make sure all lru add caches are flushed */
> invalidate_mapping_pages(mapping, 0, -1);
> + /* 99% of the time, we don't need to flush the cleancache on the bdev.
> + * But, for the strange corners, lets be cautious
> + */
> + cleancache_flush_inode(mapping);
> }
> EXPORT_SYMBOL(invalidate_bdev);
>
> --- linux-2.6.39-rc3/fs/mpage.c 2011-04-11 18:21:51.000000000 -0600
> +++ linux-2.6.39-rc3-cleancache/fs/mpage.c 2011-04-13 17:07:24.706913410 -0600
> @@ -27,6 +27,7 @@
> #include <linux/writeback.h>
> #include <linux/backing-dev.h>
> #include <linux/pagevec.h>
> +#include <linux/cleancache.h>
>
> /*
> * I/O completion handler for multipage BIOs.
> @@ -271,6 +272,12 @@ do_mpage_readpage(struct bio *bio, struc
> SetPageMappedToDisk(page);
> }
>
> + if (fully_mapped && blocks_per_page == 1 && !PageUptodate(page) &&
> + cleancache_get_page(page) == 0) {
> + SetPageUptodate(page);
> + goto confused;
> + }
> +
> /*
> * This page will go to BIO. Do we need to send this BIO off first?
> */
> --- linux-2.6.39-rc3/mm/filemap.c 2011-04-11 18:21:51.000000000 -0600
> +++ linux-2.6.39-rc3-cleancache/mm/filemap.c 2011-04-13 17:09:46.367852002 -0600
> @@ -34,6 +34,7 @@
> #include <linux/hardirq.h> /* for BUG_ON(!in_atomic()) only */
> #include <linux/memcontrol.h>
> #include <linux/mm_inline.h> /* for page_is_file_cache() */
> +#include <linux/cleancache.h>
> #include "internal.h"
>
> /*
> @@ -118,6 +119,16 @@ void __delete_from_page_cache(struct pag
> {
> struct address_space *mapping = page->mapping;
>
> + /*
> + * if we're uptodate, flush out into the cleancache, otherwise
> + * invalidate any existing cleancache entries. We can't leave
> + * stale data around in the cleancache once our page is gone
> + */
> + if (PageUptodate(page) && PageMappedToDisk(page))
> + cleancache_put_page(page);
> + else
> + cleancache_flush_page(mapping, page);
> +
First of all, thanks for resolving conflict with my patch.
Before I suggested a thing about cleancache_flush_page, cleancache_flush_inode.
what's the meaning of flush's semantic?
I thought it means invalidation.
AFAIC, how about change flush with invalidate?
--
Kind regards,
Minchan Kim
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists