Messages in this thread | | | Subject | Re: [PATCH -next 2/3] md/raid10: convert resync_lock to use seqlock | From | Yu Kuai <> | Date | Fri, 2 Sep 2022 18:53:56 +0800 |
| |
Hi,
在 2022/09/02 18:16, Guoqing Jiang 写道: > > > On 9/2/22 6:02 PM, Yu Kuai wrote: >> Hi, >> >> 在 2022/09/02 17:42, Guoqing Jiang 写道: >>> Hi, >>> >>> On 8/29/22 9:15 PM, Yu Kuai wrote: >>>> +static bool wait_barrier_nolock(struct r10conf *conf) >>>> +{ >>>> + unsigned int seq = raw_read_seqcount(&conf->resync_lock.seqcount); >>>> + >>>> + if (seq & 1) >>>> + return false; >>>> + >>>> + if (READ_ONCE(conf->barrier)) >>>> + return false; >>>> + >>>> + atomic_inc(&conf->nr_pending); >>>> + if (!read_seqcount_retry(&conf->resync_lock.seqcount, seq)) >>> >>> I think 'seq' is usually get from read_seqcount_begin. >> >> read_seqcount_begin will loop untill "req & 1" failed, I'm afraid this >> will cause high cpu usage in come cases. >> >> What I try to do here is just try once, and fall back to hold lock and >> wait if failed. > > Thanks for the explanation. > > I'd suggest to try with read_seqcount_begin/read_seqcount_retry pattern > because it is a common usage in kernel I think, then check whether the > performance drops or not. Maybe it is related to lockdep issue, but I am > not sure.
I can try read_seqcount_begin/read_seqcount_retry.
Please take a look at another thread, lockdep issue is due to inconsistent usage of lock and seqcount inside seqlock:
wait_event() only release lock, seqcount is not released.
Thansk, Kuai > > Thanks, > Guoqing > . >
| |