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
ext_lock_num++ % NR_GLOBAL_LOCKS;
mutex_lock(>fs_lock[next_lock]);
- sbi->next_lock_num++;
return next_lock;
}
>
> >
> > thanks
> >
> > --- Original Message ---
> > Sender : ??? S5(??)/??/?(???)/
> > Date : 九月 10, 2013 09:52 (GMT+09
---
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
09:52 (GMT+09:00)
Title : Re: [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
...@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!
>>
nerating: 3 > 2 > 4 > 1
So I think it's better to use atomic_add_return in round-robin method to
cost less time and reduce collide.
What's your opinion?
thanks
--- Original Message ---
Sender : ??? S5(??)/??/?(???)/
Date : 九月 10, 2013 09:52 (GMT+09:00)
Title : Re
-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
