All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wu Fengguang <fengguang.wu@intel.com>
To: Minchan Kim <minchan.kim@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-mm <linux-mm@kvack.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Ben Gamari <bgamari.foss@gmail.com>,
	Rik van Riel <riel@redhat.com>,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Nick Piggin <npiggin@kernel.dk>, Mel Gorman <mel@csn.ul.ie>
Subject: Re: [PATCH v2 2/3] move ClearPageReclaim
Date: Mon, 29 Nov 2010 16:26:51 +0800	[thread overview]
Message-ID: <20101129082651.GA26715@localhost> (raw)
In-Reply-To: <AANLkTikuriwJr-UZg9=WXXwLt-u3sywkzkpZFBV1C4Db@mail.gmail.com>

On Mon, Nov 29, 2010 at 04:16:01PM +0800, Minchan Kim wrote:
> On Mon, Nov 29, 2010 at 4:29 PM, Wu Fengguang <fengguang.wu@intel.com> wrote:
> > On Sun, Nov 28, 2010 at 11:02:56PM +0800, Minchan Kim wrote:
> >> fe3cba17 added ClearPageReclaim into clear_page_dirty_for_io for
> >> preventing fast reclaiming readahead marker page.
> >>
> >> In this series, PG_reclaim is used by invalidated page, too.
> >> If VM find the page is invalidated and it's dirty, it sets PG_reclaim
> >> to reclaim asap. Then, when the dirty page will be writeback,
> >> clear_page_dirty_for_io will clear PG_reclaim unconditionally.
> >> It disturbs this serie's goal.
> >>
> >> I think it's okay to clear PG_readahead when the page is dirty, not
> >> writeback time. So this patch moves ClearPageReadahead.
> >> This patch needs Wu's opinion.
> >
> > It's a safe change. The possibility and consequence of races are both
> > small enough. However the patch could be simplified as follows?
> 
> If all of file systems use it, I don't mind it.
> Do all of filesystems use it when the page is dirtied?
> I was not sure it.(It's why I added Cc. :)
> If it doesn't have a problem, I hope so.

Please double check, but here is my findings:

__set_page_dirty_buffers() is called by several fs' ->set_page_dirty()
which are all called by set_page_dirty().

set_page_dirty_lock() will call set_page_dirty().

__set_page_dirty_no_writeback(): it have no connection to
end_page_writeback(), so no need to set PG_reclaim.

Thanks,
Fengguang


> > --- linux-next.orig/mm/page-writeback.c 2010-11-29 15:14:54.000000000 +0800
> > +++ linux-next/mm/page-writeback.c      2010-11-29 15:15:02.000000000 +0800
> > @@ -1330,6 +1330,7 @@ int set_page_dirty(struct page *page)
> >  {
> >        struct address_space *mapping = page_mapping(page);
> >
> > +       ClearPageReclaim(page);
> >        if (likely(mapping)) {
> >                int (*spd)(struct page *) = mapping->a_ops->set_page_dirty;
> >  #ifdef CONFIG_BLOCK
> > @@ -1387,7 +1388,6 @@ int clear_page_dirty_for_io(struct page
> >
> >        BUG_ON(!PageLocked(page));
> >
> > -       ClearPageReclaim(page);
> >        if (mapping && mapping_cap_account_dirty(mapping)) {
> >                /*
> >                 * Yes, Virginia, this is indeed insane.
> >
> 
> 
> 
> -- 
> Kind regards,
> Minchan Kim

WARNING: multiple messages have this Message-ID (diff)
From: Wu Fengguang <fengguang.wu@intel.com>
To: Minchan Kim <minchan.kim@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-mm <linux-mm@kvack.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Ben Gamari <bgamari.foss@gmail.com>,
	Rik van Riel <riel@redhat.com>,
	KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Nick Piggin <npiggin@kernel.dk>, Mel Gorman <mel@csn.ul.ie>
Subject: Re: [PATCH v2 2/3] move ClearPageReclaim
Date: Mon, 29 Nov 2010 16:26:51 +0800	[thread overview]
Message-ID: <20101129082651.GA26715@localhost> (raw)
In-Reply-To: <AANLkTikuriwJr-UZg9=WXXwLt-u3sywkzkpZFBV1C4Db@mail.gmail.com>

On Mon, Nov 29, 2010 at 04:16:01PM +0800, Minchan Kim wrote:
> On Mon, Nov 29, 2010 at 4:29 PM, Wu Fengguang <fengguang.wu@intel.com> wrote:
> > On Sun, Nov 28, 2010 at 11:02:56PM +0800, Minchan Kim wrote:
> >> fe3cba17 added ClearPageReclaim into clear_page_dirty_for_io for
> >> preventing fast reclaiming readahead marker page.
> >>
> >> In this series, PG_reclaim is used by invalidated page, too.
> >> If VM find the page is invalidated and it's dirty, it sets PG_reclaim
> >> to reclaim asap. Then, when the dirty page will be writeback,
> >> clear_page_dirty_for_io will clear PG_reclaim unconditionally.
> >> It disturbs this serie's goal.
> >>
> >> I think it's okay to clear PG_readahead when the page is dirty, not
> >> writeback time. So this patch moves ClearPageReadahead.
> >> This patch needs Wu's opinion.
> >
> > It's a safe change. The possibility and consequence of races are both
> > small enough. However the patch could be simplified as follows?
> 
> If all of file systems use it, I don't mind it.
> Do all of filesystems use it when the page is dirtied?
> I was not sure it.(It's why I added Cc. :)
> If it doesn't have a problem, I hope so.

Please double check, but here is my findings:

__set_page_dirty_buffers() is called by several fs' ->set_page_dirty()
which are all called by set_page_dirty().

set_page_dirty_lock() will call set_page_dirty().

__set_page_dirty_no_writeback(): it have no connection to
end_page_writeback(), so no need to set PG_reclaim.

Thanks,
Fengguang


> > --- linux-next.orig/mm/page-writeback.c 2010-11-29 15:14:54.000000000 +0800
> > +++ linux-next/mm/page-writeback.c A  A  A 2010-11-29 15:15:02.000000000 +0800
> > @@ -1330,6 +1330,7 @@ int set_page_dirty(struct page *page)
> > A {
> > A  A  A  A struct address_space *mapping = page_mapping(page);
> >
> > + A  A  A  ClearPageReclaim(page);
> > A  A  A  A if (likely(mapping)) {
> > A  A  A  A  A  A  A  A int (*spd)(struct page *) = mapping->a_ops->set_page_dirty;
> > A #ifdef CONFIG_BLOCK
> > @@ -1387,7 +1388,6 @@ int clear_page_dirty_for_io(struct page
> >
> > A  A  A  A BUG_ON(!PageLocked(page));
> >
> > - A  A  A  ClearPageReclaim(page);
> > A  A  A  A if (mapping && mapping_cap_account_dirty(mapping)) {
> > A  A  A  A  A  A  A  A /*
> > A  A  A  A  A  A  A  A  * Yes, Virginia, this is indeed insane.
> >
> 
> 
> 
> -- 
> Kind regards,
> Minchan Kim

--
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/ .
Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2010-11-29  8:26 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-28 15:02 [PATCH v2 1/3] deactivate invalidated pages Minchan Kim
2010-11-28 15:02 ` Minchan Kim
2010-11-28 15:02 ` [PATCH v2 2/3] move ClearPageReclaim Minchan Kim
2010-11-28 15:02   ` Minchan Kim
2010-11-29  4:25   ` Rik van Riel
2010-11-29  4:25     ` Rik van Riel
2010-11-29  7:29   ` Wu Fengguang
2010-11-29  7:29     ` Wu Fengguang
2010-11-29  8:16     ` Minchan Kim
2010-11-29  8:16       ` Minchan Kim
2010-11-29  8:26       ` Wu Fengguang [this message]
2010-11-29  8:26         ` Wu Fengguang
2010-11-28 15:02 ` [PATCH v2 3/3] Prevent promotion of page in madvise_dontneed Minchan Kim
2010-11-28 15:02   ` Minchan Kim
2010-11-29  4:28   ` Rik van Riel
2010-11-29  4:28     ` Rik van Riel
2010-11-29  4:30     ` Minchan Kim
2010-11-29  4:30       ` Minchan Kim
2010-11-28 15:13 ` [PATCH v2 1/3] deactivate invalidated pages Minchan Kim
2010-11-28 15:13   ` Minchan Kim
2010-11-28 19:02 ` Rik van Riel
2010-11-28 19:02   ` Rik van Riel
2010-11-29  0:33 ` KOSAKI Motohiro
2010-11-29  0:33   ` KOSAKI Motohiro
2010-11-29  1:58   ` Ben Gamari
2010-11-29  1:58     ` Ben Gamari
2010-11-29  2:13     ` KOSAKI Motohiro
2010-11-29  2:13       ` KOSAKI Motohiro
2010-11-29  2:26       ` Ben Gamari
2010-11-29  2:26         ` Ben Gamari
2010-11-29  2:13   ` Minchan Kim
2010-11-29  2:13     ` Minchan Kim
2010-11-29  2:35     ` KOSAKI Motohiro
2010-11-29  2:35       ` KOSAKI Motohiro
2010-11-29  7:49 ` Wu Fengguang
2010-11-29  7:49   ` Wu Fengguang
2010-11-29  8:09   ` Minchan Kim
2010-11-29  8:09     ` Minchan Kim
2010-11-29 12:07 ` Mel Gorman
2010-11-29 12:07   ` Mel Gorman
2010-11-29 15:28   ` Minchan Kim
2010-11-29 15:28     ` Minchan Kim

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=20101129082651.GA26715@localhost \
    --to=fengguang.wu@intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=bgamari.foss@gmail.com \
    --cc=hannes@cmpxchg.org \
    --cc=kosaki.motohiro@jp.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mel@csn.ul.ie \
    --cc=minchan.kim@gmail.com \
    --cc=npiggin@kernel.dk \
    --cc=riel@redhat.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.