Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp1301872pxf; Fri, 12 Mar 2021 06:47:34 -0800 (PST) X-Google-Smtp-Source: ABdhPJyXJ126aaLAurm4WmeSZp3NNUW42e8/vWef4Fyu4sl+ebl0TQGT/IrIK3IWMwqVFtaCzeDv X-Received: by 2002:a17:907:162b:: with SMTP id hb43mr9142414ejc.41.1615560454445; Fri, 12 Mar 2021 06:47:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1615560454; cv=none; d=google.com; s=arc-20160816; b=XMNuTPjWfWpAJAfgTf1NgQpLJ2F0ZTTalJhq44lJ4wJoKrq1vowSYbVZWEAGBnul9B 9I1PL0eBQv6vQktHhfPGcvfws4RizfexSHGK9cTyBFkAUJNddYxPDy7eZYO8LUgQtycy T3YtFCaaCz7Z40S9cQPud6UEi+emoWXm+06U3e39lTdDk7uyWjINRA5OAnIet7jJThTQ dmxvoG0YgUxcXa7tU0MYSf8OYiKyMJYJVEjWsp8x58mzKdepJfueVVT4g2hHcC2uTcHw jDE1W439KaQcRxUbU+8m4GFcH0jo9jmODLmjri060EjOqUQaz+FenpxXlMWym/K7xH6b xMqQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=Mr1FjbtOo2oaErNudiDkdyq/FC3uXpVrOtNOsRZRzZU=; b=BKHaQKbmuKjn/OWa1IdAdWZ5Wqy3ogwhj9Q8CrqzukBHeh/auYRX+Lkz51S0969J5e lA6H6i9ZuX6o3eG3JWPMyekuJPIGC9K+zAXzUn4zF4sdtnWOQ+gVJOe/IFwKZ4h5uvPd n9k/n2loPQthwX+ErYc7K3lSKmiJVZY22Ek1VxaLwQ9vx4sy0IZxuftM/7NHy5y1rXyA BTb4GzI/nrGL4ztESOvyRZ8GW7upBS6hMEjNHTm5+/Gl0fwtIIsBe66PONNDxIaqQ4en i6KvK7wZw5Li4VU5URJ7LdLXsJr0iO/g05hy+/QmsSIgw2tbjb2zU8OH4ZF6/okiP/DZ lBGw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=OGrTW2c5; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id e9si4315688edv.149.2021.03.12.06.47.11; Fri, 12 Mar 2021 06:47:34 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=OGrTW2c5; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231336AbhCLOqJ (ORCPT + 99 others); Fri, 12 Mar 2021 09:46:09 -0500 Received: from mail.kernel.org ([198.145.29.99]:35902 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230302AbhCLOpv (ORCPT ); Fri, 12 Mar 2021 09:45:51 -0500 Received: by mail.kernel.org (Postfix) with ESMTPSA id 4536A64FD6; Fri, 12 Mar 2021 14:45:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1615560350; bh=5OcUS67DMAnxCxpF2YhrDjA4ZH7gotBBF3aF5cp7VAo=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=OGrTW2c5kQMZqDLHOuPubJDXsH5iNNl9G1C8bABPxHyPcm06lamlCYPxjL/7xokSu 6xqdQEaz0tP0k8l4U3D3jCYKk3PxisKyYJ9L5pw2AdXmglGrmAxermQHLMydovsQSS IA2wUtJS7RrAgy28DpmknVJbOyZw2fAvOZcmmZbs= Date: Fri, 12 Mar 2021 15:45:48 +0100 From: Greg KH To: Daeho Jeong Cc: linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, kernel-team@android.com, Daeho Jeong Subject: Re: [PATCH v4] f2fs: add sysfs nodes to get runtime compression stat Message-ID: References: <20210312122531.2717093-1-daeho43@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.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. > > > 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