om;
>> linux-fsde...@vger.kernel.org; linux-kernel@vger.kernel.org;
>> linux-f2fs-de...@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
g;
> linux-f2fs-de...@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 follo
> Subject: Re: Re: [f2fs-dev][PATCH] f2fs: optimize fs_lock for better
performance
>
> Hi,
>
> 2013/9/11 Chao Yu
> >
> > Hi Kim,
> >
> > I did some tests as you mention of using random instead of spin_lock.
> > The test model is as following:
> >
---
Sender : Russ Knize
Date : 九月 07, 2013 04:25 (GMT+09:00)
Title : Re: [f2fs-dev] [PATCH] f2fs: optimize fs_lock for better
performance
I encountered this same issue recently and solved it in much the same
way. Can we rename "spin_lock" to something more meaningful?
This
t;> Agree. This fs_lock here is used to protect the xattr from parallel
>>> modification,
>>> but here is in the initxattrs routine, parallel modification can not
>>> happen.
>>> And in the normal setxattr routine the inode->i_mutex (vfs layer) is used
&g
Hi Gu,
2013/9/11 Gu Zheng :
> 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
modification can not
>> happen.
>> And in the normal setxattr routine the inode->i_mutex (vfs layer) is used
>> to
>> avoid parallel modification. So I think this fs_lock is needless.
>> Am I missing something?
>>
>> Regards,
>> Gu
>>
>> >
st with sbi->next_lock_num++ only instead of using
atomic_add_return?
IMO, this is just an integer value and still I don't think this value should
be covered by any kind of locks.
Thanks,
>
> thanks
>
> --- Original Message ---
> Sender : ??? S5(??)/??/?????(???)/
an integer value and still I don't think this value should
be covered by any kind of locks.
Thanks,
thanks
--- Original Message ---
Sender : ???jaegeuk@samsung.com S5(??)/??/?(???)/
Date : 九月 10, 2013 09:52 (GMT+09:00)
Title : Re: [f2fs-dev][PATCH] f2fs: optimize fs_lock
when f2fs_initxattrs() is called.
Let's think about ut in more detail.
Thanks,
thanks again!
--- Original Message ---
Sender : Russ Knizeruss.kn...@motorola.com
Date : 九月 07, 2013 04:25 (GMT+09:00)
Title : Re: [f2fs-dev] [PATCH] f2fs: optimize fs_lock
Hi Gu,
2013/9/11 Gu Zheng guz.f...@cn.fujitsu.com:
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
in more detail.
Thanks,
thanks again!
--- Original Message ---
Sender : Russ Knizeruss.kn...@motorola.com
Date : 九月 07, 2013 04:25 (GMT+09:00)
Title : Re: [f2fs-dev] [PATCH] f2fs: optimize fs_lock for better
performance
I encountered this same issue
!
--- Original Message ---
Sender : Russ Knizeruss.kn...@motorola.com
Date : 九月 07, 2013 04:25 (GMT+09:00)
Title : Re: [f2fs-dev] [PATCH] f2fs: optimize fs_lock for better
performance
I encountered this same issue recently and solved it in much the same
way. Can we rename spin_lock to something
-dev][PATCH] f2fs: optimize fs_lock for better
performance
Hi,
2013/9/11 Chao Yu chao2...@samsung.com
Hi Kim,
I did some tests as you mention of using random instead of spin_lock.
The test model is as following:
eight threads race to grab one of eight locks for one thousand times
...@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
@vger.kernel.org;
linux-f2fs-de...@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
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
Hi Jaegeuk,
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
d parallel modification. So I think this fs_lock is needless.
Am I missing something?
Regards,
Gu
> level, since this case only happens when f2fs_initxattrs() is called.
> Let's think about ut in more detail.
> Thanks,
>
>>
>>
>>
>> thanks again!
>>
: [f2fs-dev][PATCH] f2fs: optimize fs_lock for better performance
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 lo
-dev][PATCH] f2fs: optimize fs_lock for better performance
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
!
--- Original Message ---
Sender : Russ Knizeruss.kn...@motorola.com
Date : 九月 07, 2013 04:25 (GMT+09:00)
Title : Re: [f2fs-dev] [PATCH] f2fs: optimize fs_lock for better
performance
I encountered this same issue recently and solved it in much the same
way. Can we rename
Hi Jaegeuk,
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
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
;
>
>
> thanks again!
>
>
>
> --- Original Message ---
>
> Sender : Russ Knize
>
> Date : 九月 07, 2013 04:25 (GMT+09:00)
>
> Title : Re: [f2fs-dev] [PATCH] f2fs: optimize fs_lock for better
> performance
>
>
>
> I encountere
Hi,
Nice catch.
This is definitely a bug where one thread grabbed two fs_locks across
the same flow.
Any idea?
Thanks,
2013-09-06 (금), 14:25 -0500, Russ Knize:
> I encountered this same issue recently and solved it in much the same
> way. Can we rename "spin_lock" to something more meaningful?
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.
So,
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.
So,
Hi,
Nice catch.
This is definitely a bug where one thread grabbed two fs_locks across
the same flow.
Any idea?
Thanks,
2013-09-06 (금), 14:25 -0500, Russ Knize:
I encountered this same issue recently and solved it in much the same
way. Can we rename spin_lock to something more meaningful?
04:25 (GMT+09:00)
Title : Re: [f2fs-dev] [PATCH] f2fs: optimize fs_lock for better
performance
I encountered this same issue recently and solved it in much the same
way. Can we rename spin_lock to something more meaningful?
This race actually exposed a potential deadlock between
30 matches
Mail list logo