Re: [PATCH v4] f2fs: add sysfs nodes to get runtime compression stat

[Greg KH <gregkh@linuxfoundation.org>]

A: http://en.wikipedia.org/wiki/Top_post
Q: Were do I find info about this thing called top-posting?
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

A: No.
Q: Should I include quotations after my reply?

http://daringfireball.net/2007/07/on_top


On Fri, Mar 12, 2021 at 11:37:29PM +0900, Daeho Jeong wrote:
> As you can see, if we're doing like the below.
> 
> sbi->compr_written_block += blocks;
> 
> Let's assume the initial value as 0.
> 
> <thread A>                                             <thread B>
> sbi->compr_written_block = 0;
> 
> sbi->compr_written_block = 0;
> +blocks(3);
>                                                                + blocks(2);
> sbi->compr_written_block = 3;
> 
> sbi->compr_written_block = 2;
> 
> Finally, we end up with 2, not 5.
> 
> As more threads are participating it, we might miss more counting.

Are you sure?  Isn't adding a number something that should happen in a
"safe" way?

And if you miss 2 blocks, who cares?  What is so critical about these
things that you take the cache flush of 2 atomic writes just for a
debugging statistic?

Why not just take 1 lock for everything if it's so important to get
these "correct"?

What is the performance throughput degradation of adding 2 atomic writes
to each time you write a block?

But really, will you ever notice missing a few, even if that could be
possible on your cpu (and I strongly doubt most modern cpus will miss
this...)

But this isn't my code, I just hate seeing atomic variables used for
silly things like debugging stats when they do not seem to be really
needed.  So if you want to keep them, go ahead, but realize that the
number you are reading has nothing to do with being "atomic" at all.

thanks,

greg k-h