All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jaegeuk Kim <jaegeuk@kernel.org>
To: Fan Li <fanofcode.li@samsung.com>
Cc: 'Chao Yu' <chao@kernel.org>, linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [PATCH] f2fs: modify the readahead method in ra_node_page()
Date: Mon, 7 Mar 2016 18:29:33 -0800	[thread overview]
Message-ID: <20160308022933.GC44902@jaegeuk.gateway> (raw)
In-Reply-To: <001b01d17824$4c22f450$e468dcf0$@samsung.com>

> > >>>  fs/f2fs/node.c |    9 ++++-----
> > >>>  1 file changed, 4 insertions(+), 5 deletions(-)
> > >>>
> > >>> diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c index 511c0e7..6d8f107
> > >>> 100644
> > >>> --- a/fs/f2fs/node.c
> > >>> +++ b/fs/f2fs/node.c
> > >>> @@ -1080,12 +1080,11 @@ void ra_node_page(struct f2fs_sb_info *sbi, nid_t nid)
> > >>>                 return;
> > >>>         f2fs_bug_on(sbi, check_nid_range(sbi, nid));
> > >>>
> > >>> -       apage = find_get_page(NODE_MAPPING(sbi), nid);
> > >>> -       if (apage && PageUptodate(apage)) {
> > >>> -               f2fs_put_page(apage, 0);
> > >>> +       rcu_read_lock();
> > >>> +       apage = radix_tree_lookup(&NODE_MAPPING(sbi)->page_tree, nid);
> > >>> +       rcu_read_unlock();
> > >>> +       if (apage)
> > >>>                 return;
> > >>> -       }
> > >>> -       f2fs_put_page(apage, 0);
> > >>
> > >> How about use trylock_page to avoid contention here?
> > >
> > > I thought about that, but after I saw the __do_page_cache_readahead(),
> > > I think that's better.
> > > they works almost the same, but it reduces the performance by altering
> > > reference count and trying to lock the page.
> > >
> > > The only difference between this two methods is how to deal a page
> > 
> > Concurrent threads can both pass the rcu lookuping at the same time, and then they will be serialized by grab_cache_page invoking,
> > which altering second thread to read node page synchronously instead of reading asynchronously. IMO, we can afford to reference
> > and trylock which takes litte overhead of CPU in order to avoid potential synchronously readahead for node page.
> 
> My point is that this patch can avoid potential synchronously readahead for node page without taking such overhead.
> The difference is very small and the method has already been used in vfs codes.

Let me go with Fan's patch at this moment.
Then, it'd good to investigate how contention occurs here later.

Thanks,

> 
> > 
> > Thanks,
> > 
> > > which is left unlock and not uptodate in mapping. I think only cause
> > > of such page seems to be IO error, and it's too rare to call for optimization.
> > >
> > >>
> > >> diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c index 26eb441..9cdb6f2
> > >> 100644
> > >> --- a/fs/f2fs/node.c
> > >> +++ b/fs/f2fs/node.c
> > >> @@ -1085,15 +1085,14 @@ void ra_node_page(struct f2fs_sb_info *sbi, nid_t nid)
> > >>         f2fs_bug_on(sbi, check_nid_range(sbi, nid));
> > >>
> > >>         apage = find_get_page(NODE_MAPPING(sbi), nid);
> > >> -       if (apage && PageUptodate(apage)) {
> > >> +       if (!apage) {
> > >> +               apage = grab_cache_page(NODE_MAPPING(sbi), nid);
> > >> +               if (!apage)
> > >> +                       return;
> > >> +       } else if (PageUptodate(apage) || !trylock_page(apage)) {
> > >>                 f2fs_put_page(apage, 0);
> > >>                 return;
> > >>         }
> > >> -       f2fs_put_page(apage, 0);
> > >> -
> > >> -       apage = grab_cache_page(NODE_MAPPING(sbi), nid);
> > >> -       if (!apage)
> > >> -               return;
> > >>
> > >>         err = read_node_page(apage, READA);
> > >>         f2fs_put_page(apage, err ? 1 : 0);
> > >>
> > >> Thanks,
> > >>
> > >>>
> > >>>         apage = grab_cache_page(NODE_MAPPING(sbi), nid);
> > >>>         if (!apage)
> > >>> --
> > >>> 1.7.9.5
> > >>>
> > >>>
> > >>> --------------------------------------------------------------------
> > >>> --
> > >>> --------
> > >>> Site24x7 APM Insight: Get Deep Visibility into Application
> > >>> Performance APM + Mobile APM + RUM: Monitor 3 App instances at just
> > >>> $35/Month Monitor end-to-end web transactions and take corrective
> > >>> actions now Troubleshoot faster and improve end-user experience. Signup Now!
> > >>> http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
> > >>> _______________________________________________
> > >>> Linux-f2fs-devel mailing list
> > >>> Linux-f2fs-devel@lists.sourceforge.net
> > >>> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
> > >
> > >
> > > ----------------------------------------------------------------------
> > > --------
> > > Site24x7 APM Insight: Get Deep Visibility into Application Performance
> > > APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
> > > Monitor end-to-end web transactions and take corrective actions now
> > > Troubleshoot faster and improve end-user experience. Signup Now!
> > > http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
> > > _______________________________________________
> > > Linux-f2fs-devel mailing list
> > > Linux-f2fs-devel@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
> > >

------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://makebettercode.com/inteldaal-eval

      reply	other threads:[~2016-03-08  2:29 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-29  6:29 [PATCH] f2fs: modify the readahead method in ra_node_page() Fan Li
2016-03-01  9:53 ` Chao Yu
2016-03-02  3:11   ` Fan Li
2016-03-03 13:32     ` Chao Yu
2016-03-07  3:48       ` Fan Li
2016-03-08  2:29         ` Jaegeuk Kim [this message]

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=20160308022933.GC44902@jaegeuk.gateway \
    --to=jaegeuk@kernel.org \
    --cc=chao@kernel.org \
    --cc=fanofcode.li@samsung.com \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    /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.