From: 俞超 <chao2.yu@samsung.com>
To: 'Gu Zheng' <guz.fnst@cn.fujitsu.com>, jaegeuk.kim@samsung.com
Cc: linux-fsdevel@vger.kernel.org, shu.tan@samsung.com,
linux-kernel@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [PATCH] f2fs: optimize fs_lock for better performance
Date: Thu, 12 Sep 2013 10:40:27 +0800 [thread overview]
Message-ID: <001001ceaf61$a4ea9a90$eebfcfb0$@samsung.com> (raw)
In-Reply-To: <523001B6.3080506@cn.fujitsu.com>
Hi Gu
> -----Original Message-----
> From: Gu Zheng [mailto:guz.fnst@cn.fujitsu.com]
> Sent: Wednesday, September 11, 2013 1:38 PM
> To: jaegeuk.kim@samsung.com
> Cc: chao2.yu@samsung.com; shu.tan@samsung.com;
> linux-fsdevel@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-f2fs-devel@lists.sourceforge.net
> Subject: Re: [f2fs-dev][PATCH] f2fs: optimize fs_lock for better performance
>
> Hi Jaegeuk, Chao,
>
> On 09/10/2013 08:52 AM, Jaegeuk Kim wrote:
>
> > Hi,
> >
> > At first, thank you for the report and please follow the email writing
> > rules. :)
> >
> > Anyway, I agree to the below issue.
> > One thing that I can think of is that we don't need to use the
> > spin_lock, since we don't care about the exact lock number, but just
> > need to get any not-collided number.
>
> IMHO, just moving sbi->next_lock_num++ before
> mutex_lock(&sbi->fs_lock[next_lock])
> can avoid unbalance issue mostly.
> IMO, the case two or more threads increase sbi->next_lock_num in the same
> time is really very very little. If you think it is not rigorous, change
> next_lock_num to atomic one can fix it.
> What's your opinion?
>
> Regards,
> Gu
I did the test sbi->next_lock_num++ compare with the atomic one,
And I found performance of them is almost the same under a small number thread racing.
So as your and Kim's opinion, it's enough to use "sbi->next_lock_num++" to fix this issue.
Thanks for the advice.
>
> >
> > So, how about removing the spin_lock?
> > And how about using a random number?
>
> > Thanks,
> >
> > 2013-09-06 (금), 09:48 +0000, Chao Yu:
> >> Hi Kim:
> >>
> >> I think there is a performance problem: when all sbi->fs_lock is
> >> holded,
> >>
> >> then all other threads may get the same next_lock value from
> >> sbi->next_lock_num in function mutex_lock_op,
> >>
> >> and wait to get the same lock at position fs_lock[next_lock], it
> >> unbalance the fs_lock usage.
> >>
> >> It may lost performance when we do the multithread test.
> >>
> >>
> >>
> >> Here is the patch to fix this problem:
> >>
> >>
> >>
> >> Signed-off-by: Yu Chao <chao2.yu@samsung.com>
> >>
> >> diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> >>
> >> old mode 100644
> >>
> >> new mode 100755
> >>
> >> index 467d42d..983bb45
> >>
> >> --- a/fs/f2fs/f2fs.h
> >>
> >> +++ b/fs/f2fs/f2fs.h
> >>
> >> @@ -371,6 +371,7 @@ struct f2fs_sb_info {
> >>
> >> struct mutex fs_lock[NR_GLOBAL_LOCKS]; /* blocking FS
> >> operations */
> >>
> >> struct mutex node_write; /* locking node
> writes
> >> */
> >>
> >> struct mutex writepages; /* mutex for
> >> writepages() */
> >>
> >> + spinlock_t spin_lock; /* lock for
> >> next_lock_num */
> >>
> >> unsigned char next_lock_num; /* round-robin
> global
> >> locks */
> >>
> >> int por_doing; /* recovery is doing
> >> or not */
> >>
> >> int on_build_free_nids; /* build_free_nids is
> >> doing */
> >>
> >> @@ -533,15 +534,19 @@ static inline void mutex_unlock_all(struct
> >> f2fs_sb_info *sbi)
> >>
> >>
> >>
> >> static inline int mutex_lock_op(struct f2fs_sb_info *sbi)
> >>
> >> {
> >>
> >> - unsigned char next_lock = sbi->next_lock_num %
> >> NR_GLOBAL_LOCKS;
> >>
> >> + unsigned char next_lock;
> >>
> >> int i = 0;
> >>
> >>
> >>
> >> for (; i < NR_GLOBAL_LOCKS; i++)
> >>
> >> if (mutex_trylock(&sbi->fs_lock[i]))
> >>
> >> return i;
> >>
> >>
> >>
> >> - mutex_lock(&sbi->fs_lock[next_lock]);
> >>
> >> + spin_lock(&sbi->spin_lock);
> >>
> >> + next_lock = sbi->next_lock_num % NR_GLOBAL_LOCKS;
> >>
> >> sbi->next_lock_num++;
> >>
> >> + spin_unlock(&sbi->spin_lock);
> >>
> >> +
> >>
> >> + mutex_lock(&sbi->fs_lock[next_lock]);
> >>
> >> return next_lock;
> >>
> >> }
> >>
> >>
> >>
> >> diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
> >>
> >> old mode 100644
> >>
> >> new mode 100755
> >>
> >> index 75c7dc3..4f27596
> >>
> >> --- a/fs/f2fs/super.c
> >>
> >> +++ b/fs/f2fs/super.c
> >>
> >> @@ -657,6 +657,7 @@ static int f2fs_fill_super(struct super_block
> >> *sb, void *data, int silent)
> >>
> >> mutex_init(&sbi->cp_mutex);
> >>
> >> for (i = 0; i < NR_GLOBAL_LOCKS; i++)
> >>
> >> mutex_init(&sbi->fs_lock[i]);
> >>
> >> + spin_lock_init(&sbi->spin_lock);
> >>
> >> mutex_init(&sbi->node_write);
> >>
> >> sbi->por_doing = 0;
> >>
> >> spin_lock_init(&sbi->stat_lock);
> >>
> >> (END)
> >>
> >>
> >>
> >>
> >>
> >>
> >
>
>
> =
------------------------------------------------------------------------------
How ServiceNow helps IT people transform IT departments:
1. Consolidate legacy IT systems to a single system of record for IT
2. Standardize and globalize service processes across IT
3. Implement zero-touch automation to replace manual, redundant tasks
http://pubads.g.doubleclick.net/gampad/clk?id=51271111&iu=/4140/ostg.clktrk
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
next prev parent reply other threads:[~2013-09-12 2:42 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <88.C4.11914.9D4A9225@epcpsbge6.samsung.com>
2013-09-10 0:52 ` [f2fs-dev][PATCH] f2fs: optimize fs_lock for better performance Jaegeuk Kim
2013-09-11 3:13 ` [PATCH] " Gu Zheng
2013-09-11 5:37 ` Gu Zheng
2013-09-11 13:22 ` [f2fs-dev] " Kim Jaegeuk
2013-09-12 2:40 ` 俞超 [this message]
2013-09-12 3:17 ` [PATCH V2] " Gu Zheng
2013-09-12 3:18 ` [PATCH] " Gu Zheng
[not found] <04.C0.13361.61DDA225@epcpsbge5.samsung.com>
2013-09-10 0:59 ` Re: [f2fs-dev] " Jaegeuk Kim
2013-09-10 4:17 ` Russ Knize
2013-09-11 3:22 ` Gu Zheng
2013-09-11 3:47 ` Russ Knize
2013-09-07 8:00 Chao Yu
-- strict thread matches above, loose matches on Subject: below --
2013-09-06 9:48 Chao Yu
2013-09-06 19:25 ` Russ Knize
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='001001ceaf61$a4ea9a90$eebfcfb0$@samsung.com' \
--to=chao2.yu@samsung.com \
--cc=guz.fnst@cn.fujitsu.com \
--cc=jaegeuk.kim@samsung.com \
--cc=linux-f2fs-devel@lists.sourceforge.net \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=shu.tan@samsung.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).