| Message ID | 20230914154553.71939-1-shikemeng@huaweicloud.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | fuse: remove unneeded lock which protecting update of congestion_threshold | expand |
On 9/14/23 17:45, Kemeng Shi wrote: > Commit 670d21c6e17f6 ("fuse: remove reliance on bdi congestion") change how > congestion_threshold is used and lock in > fuse_conn_congestion_threshold_write is not needed anymore. > 1. Access to supe_block is removed along with removing of bdi congestion. > Then down_read(&fc->killsb) which protecting access to super_block is no > needed. > 2. Compare num_background and congestion_threshold without holding > bg_lock. Then there is no need to hold bg_lock to update > congestion_threshold. > > Signed-off-by: Kemeng Shi <shikemeng@huaweicloud.com> > --- > fs/fuse/control.c | 4 ---- > 1 file changed, 4 deletions(-) > > diff --git a/fs/fuse/control.c b/fs/fuse/control.c > index 247ef4f76761..c5d7bf80efed 100644 > --- a/fs/fuse/control.c > +++ b/fs/fuse/control.c > @@ -174,11 +174,7 @@ static ssize_t fuse_conn_congestion_threshold_write(struct file *file, > if (!fc) > goto out; > > - down_read(&fc->killsb); > - spin_lock(&fc->bg_lock); > fc->congestion_threshold = val; > - spin_unlock(&fc->bg_lock); > - up_read(&fc->killsb); > fuse_conn_put(fc); > out: > return ret; Yeah, I don't see readers holding any of these locks. I just wonder if it wouldn't be better to use WRITE_ONCE to ensure a single atomic operation to store the value. Thanks, Bernd
on 9/16/2023 7:06 PM, Bernd Schubert wrote: > > > On 9/14/23 17:45, Kemeng Shi wrote: >> Commit 670d21c6e17f6 ("fuse: remove reliance on bdi congestion") change how >> congestion_threshold is used and lock in >> fuse_conn_congestion_threshold_write is not needed anymore. >> 1. Access to supe_block is removed along with removing of bdi congestion. >> Then down_read(&fc->killsb) which protecting access to super_block is no >> needed. >> 2. Compare num_background and congestion_threshold without holding >> bg_lock. Then there is no need to hold bg_lock to update >> congestion_threshold. >> >> Signed-off-by: Kemeng Shi <shikemeng@huaweicloud.com> >> --- >> fs/fuse/control.c | 4 ---- >> 1 file changed, 4 deletions(-) >> >> diff --git a/fs/fuse/control.c b/fs/fuse/control.c >> index 247ef4f76761..c5d7bf80efed 100644 >> --- a/fs/fuse/control.c >> +++ b/fs/fuse/control.c >> @@ -174,11 +174,7 @@ static ssize_t fuse_conn_congestion_threshold_write(struct file *file, >> if (!fc) >> goto out; >> - down_read(&fc->killsb); >> - spin_lock(&fc->bg_lock); >> fc->congestion_threshold = val; >> - spin_unlock(&fc->bg_lock); >> - up_read(&fc->killsb); >> fuse_conn_put(fc); >> out: >> return ret; > > Yeah, I don't see readers holding any of these locks. > I just wonder if it wouldn't be better to use WRITE_ONCE to ensure a single atomic operation to store the value. Sure, WRITE_ONCE looks better. I wonder if we should use READ_ONCE from reader. Would like to get any advice. Thanks! > > > Thanks, > Bernd >
On 9/19/23 08:11, Kemeng Shi wrote: > > > on 9/16/2023 7:06 PM, Bernd Schubert wrote: >> >> >> On 9/14/23 17:45, Kemeng Shi wrote: >>> Commit 670d21c6e17f6 ("fuse: remove reliance on bdi congestion") change how >>> congestion_threshold is used and lock in >>> fuse_conn_congestion_threshold_write is not needed anymore. >>> 1. Access to supe_block is removed along with removing of bdi congestion. >>> Then down_read(&fc->killsb) which protecting access to super_block is no >>> needed. >>> 2. Compare num_background and congestion_threshold without holding >>> bg_lock. Then there is no need to hold bg_lock to update >>> congestion_threshold. >>> >>> Signed-off-by: Kemeng Shi <shikemeng@huaweicloud.com> >>> --- >>> fs/fuse/control.c | 4 ---- >>> 1 file changed, 4 deletions(-) >>> >>> diff --git a/fs/fuse/control.c b/fs/fuse/control.c >>> index 247ef4f76761..c5d7bf80efed 100644 >>> --- a/fs/fuse/control.c >>> +++ b/fs/fuse/control.c >>> @@ -174,11 +174,7 @@ static ssize_t fuse_conn_congestion_threshold_write(struct file *file, >>> if (!fc) >>> goto out; >>> - down_read(&fc->killsb); >>> - spin_lock(&fc->bg_lock); >>> fc->congestion_threshold = val; >>> - spin_unlock(&fc->bg_lock); >>> - up_read(&fc->killsb); >>> fuse_conn_put(fc); >>> out: >>> return ret; >> >> Yeah, I don't see readers holding any of these locks. >> I just wonder if it wouldn't be better to use WRITE_ONCE to ensure a single atomic operation to store the value. > Sure, WRITE_ONCE looks better. I wonder if we should use READ_ONCE from reader. > Would like to get any advice. Thanks! I'm not entirely sure either, but I _think_ the compiler is free to store a 32 bit value with multiple operations (like 2 x 16 bit). In that case a competing reading thread might read garbage... Although I don't see this documented here https://www.kernel.org/doc/Documentation/memory-barriers.txt Though documented there is that the compile is free to optimize out the storage at all, see "(*) Similarly, the compiler is within its rights to omit a store entirely" Regarding READ_ONCE, I don't have a strong opinion, if the compiler makes some optimizations and the value would be wrong for a few cycles, would that matter for that variable? Unless the compiler would be really creative and the variable would get never updated... For sure READ_ONCE would be safer, but I don't know if it is needed SSee section "The compiler is within its rights to omit a load entirely if it know" in the document above. Thanks, Bernd
on 9/19/2023 9:12 PM, Bernd Schubert wrote: > > > On 9/19/23 08:11, Kemeng Shi wrote: >> >> >> on 9/16/2023 7:06 PM, Bernd Schubert wrote: >>> >>> >>> On 9/14/23 17:45, Kemeng Shi wrote: >>>> Commit 670d21c6e17f6 ("fuse: remove reliance on bdi congestion") change how >>>> congestion_threshold is used and lock in >>>> fuse_conn_congestion_threshold_write is not needed anymore. >>>> 1. Access to supe_block is removed along with removing of bdi congestion. >>>> Then down_read(&fc->killsb) which protecting access to super_block is no >>>> needed. >>>> 2. Compare num_background and congestion_threshold without holding >>>> bg_lock. Then there is no need to hold bg_lock to update >>>> congestion_threshold. >>>> >>>> Signed-off-by: Kemeng Shi <shikemeng@huaweicloud.com> >>>> --- >>>> fs/fuse/control.c | 4 ---- >>>> 1 file changed, 4 deletions(-) >>>> >>>> diff --git a/fs/fuse/control.c b/fs/fuse/control.c >>>> index 247ef4f76761..c5d7bf80efed 100644 >>>> --- a/fs/fuse/control.c >>>> +++ b/fs/fuse/control.c >>>> @@ -174,11 +174,7 @@ static ssize_t fuse_conn_congestion_threshold_write(struct file *file, >>>> if (!fc) >>>> goto out; >>>> - down_read(&fc->killsb); >>>> - spin_lock(&fc->bg_lock); >>>> fc->congestion_threshold = val; >>>> - spin_unlock(&fc->bg_lock); >>>> - up_read(&fc->killsb); >>>> fuse_conn_put(fc); >>>> out: >>>> return ret; >>> >>> Yeah, I don't see readers holding any of these locks. >>> I just wonder if it wouldn't be better to use WRITE_ONCE to ensure a single atomic operation to store the value. >> Sure, WRITE_ONCE looks better. I wonder if we should use READ_ONCE from reader. >> Would like to get any advice. Thanks! > Sorry for the dealy - it toke me some time to go through the barrier documents. > I'm not entirely sure either, but I _think_ the compiler is free to store a 32 bit value with multiple operations (like 2 x 16 bit). In that case a competing reading thread might read garbage... > Although I don't see this documented here > https://www.kernel.org/doc/Documentation/memory-barriers.txt I found this is documented in section "(*) For aligned memory locations whose size allows them to be accessed..." Then WRITE_ONCE is absolutely needed now as you menthioned before. > Though documented there is that the compile is free to optimize out the storage at all, see > "(*) Similarly, the compiler is within its rights to omit a store entirely" > > > Regarding READ_ONCE, I don't have a strong opinion, if the compiler makes some optimizations and the value would be wrong for a few cycles, would that matter for that variable? Unless the compiler would be really creative and the variable would get never updated... For sure READ_ONCE would be safer, but I don't know if it is needed > SSee section > "The compiler is within its rights to omit a load entirely if it know" > in the document above. I go through all examples of optimizations in document and congestion_threshold has no same trouble descripted in document. For specifc case you menthioned that "The compiler is within its rights to omit a load entirely if it know". The compiler will keep the first load and only omit successive loads from same variable in loop. As there is no repeat loading from congestion_threshold in loop, congestion_threshold is out of this trouble. Anyway, congestion_threshold is more like a hint and the worst case is that it is stale for a few cycles. I prefer to keep reading congestion_threshold without READ_ONCE and will do it in next version if it's fine to you. Thanks! > > Thanks, > Bernd > > > >
On 9/27/23 05:04, Kemeng Shi wrote: > > > on 9/19/2023 9:12 PM, Bernd Schubert wrote: >> >> >> On 9/19/23 08:11, Kemeng Shi wrote: >>> >>> >>> on 9/16/2023 7:06 PM, Bernd Schubert wrote: >>>> >>>> >>>> On 9/14/23 17:45, Kemeng Shi wrote: >>>>> Commit 670d21c6e17f6 ("fuse: remove reliance on bdi congestion") change how >>>>> congestion_threshold is used and lock in >>>>> fuse_conn_congestion_threshold_write is not needed anymore. >>>>> 1. Access to supe_block is removed along with removing of bdi congestion. >>>>> Then down_read(&fc->killsb) which protecting access to super_block is no >>>>> needed. >>>>> 2. Compare num_background and congestion_threshold without holding >>>>> bg_lock. Then there is no need to hold bg_lock to update >>>>> congestion_threshold. >>>>> >>>>> Signed-off-by: Kemeng Shi <shikemeng@huaweicloud.com> >>>>> --- >>>>> fs/fuse/control.c | 4 ---- >>>>> 1 file changed, 4 deletions(-) >>>>> >>>>> diff --git a/fs/fuse/control.c b/fs/fuse/control.c >>>>> index 247ef4f76761..c5d7bf80efed 100644 >>>>> --- a/fs/fuse/control.c >>>>> +++ b/fs/fuse/control.c >>>>> @@ -174,11 +174,7 @@ static ssize_t fuse_conn_congestion_threshold_write(struct file *file, >>>>> if (!fc) >>>>> goto out; >>>>> - down_read(&fc->killsb); >>>>> - spin_lock(&fc->bg_lock); >>>>> fc->congestion_threshold = val; >>>>> - spin_unlock(&fc->bg_lock); >>>>> - up_read(&fc->killsb); >>>>> fuse_conn_put(fc); >>>>> out: >>>>> return ret; >>>> >>>> Yeah, I don't see readers holding any of these locks. >>>> I just wonder if it wouldn't be better to use WRITE_ONCE to ensure a single atomic operation to store the value. >>> Sure, WRITE_ONCE looks better. I wonder if we should use READ_ONCE from reader. >>> Would like to get any advice. Thanks! >> > Sorry for the dealy - it toke me some time to go through the barrier documents. >> I'm not entirely sure either, but I _think_ the compiler is free to store a 32 bit value with multiple operations (like 2 x 16 bit). In that case a competing reading thread might read garbage... >> Although I don't see this documented here >> https://www.kernel.org/doc/Documentation/memory-barriers.txt > I found this is documented in section > "(*) For aligned memory locations whose size allows them to be accessed..." > Then WRITE_ONCE is absolutely needed now as you menthioned before. >> Though documented there is that the compile is free to optimize out the storage at all, see >> "(*) Similarly, the compiler is within its rights to omit a store entirely" >> >> >> Regarding READ_ONCE, I don't have a strong opinion, if the compiler makes some optimizations and the value would be wrong for a few cycles, would that matter for that variable? Unless the compiler would be really creative and the variable would get never updated... For sure READ_ONCE would be safer, but I don't know if it is needed >> SSee section >> "The compiler is within its rights to omit a load entirely if it know" >> in the document above. > I go through all examples of optimizations in document and congestion_threshold > has no same trouble descripted in document. > For specifc case you menthioned that "The compiler is within its rights to omit > a load entirely if it know". The compiler will keep the first load and only omit > successive loads from same variable in loop. As there is no repeat loading from > congestion_threshold in loop, congestion_threshold is out of this trouble. > Anyway, congestion_threshold is more like a hint and the worst case is that it is > stale for a few cycles. I prefer to keep reading congestion_threshold without > READ_ONCE and will do it in next version if it's fine to you. Thanks! Sounds good to me, thanks for reading the document carefully! Bernd
diff --git a/fs/fuse/control.c b/fs/fuse/control.c index 247ef4f76761..c5d7bf80efed 100644 --- a/fs/fuse/control.c +++ b/fs/fuse/control.c @@ -174,11 +174,7 @@ static ssize_t fuse_conn_congestion_threshold_write(struct file *file, if (!fc) goto out; - down_read(&fc->killsb); - spin_lock(&fc->bg_lock); fc->congestion_threshold = val; - spin_unlock(&fc->bg_lock); - up_read(&fc->killsb); fuse_conn_put(fc); out: return ret;
Commit 670d21c6e17f6 ("fuse: remove reliance on bdi congestion") change how congestion_threshold is used and lock in fuse_conn_congestion_threshold_write is not needed anymore. 1. Access to supe_block is removed along with removing of bdi congestion. Then down_read(&fc->killsb) which protecting access to super_block is no needed. 2. Compare num_background and congestion_threshold without holding bg_lock. Then there is no need to hold bg_lock to update congestion_threshold. Signed-off-by: Kemeng Shi <shikemeng@huaweicloud.com> --- fs/fuse/control.c | 4 ---- 1 file changed, 4 deletions(-)