From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Snitzer Subject: Re: [PATCH v2 4/6] block: switch to per-cpu in-flight counters Date: Wed, 5 Dec 2018 13:03:47 -0500 Message-ID: <20181205180347.GA9966@redhat.com> References: <20181130222226.77216-1-snitzer@redhat.com> <20181130222226.77216-5-snitzer@redhat.com> <20181205174942.GA9838@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com To: Jens Axboe Cc: linux-block@vger.kernel.org, dm-devel@redhat.com, Mikulas Patocka List-Id: dm-devel.ids On Wed, Dec 05 2018 at 12:54pm -0500, Jens Axboe wrote: > On 12/5/18 10:49 AM, Mike Snitzer wrote: > > On Wed, Dec 05 2018 at 12:30pm -0500, > > Jens Axboe wrote: > > > >> There's also no need to pass in the cpu, if we're not running with > >> preempt disabled already we have a problem. > > > > Why should this be any different than the part_stat_* interfaces? > > __part_stat_add(), part_stat_read(), etc also use > > per_cpu_ptr((part)->dkstats, (cpu) accessors. > > Maybe audit which ones actually need it? To answer the specific question, > it's silly to pass in the cpu, if we're pinned already. That's true > both programatically, but also for someone reading the code. I understand you'd like to avoid excess interface baggage. But seems to me we'd be better off being consistent, when extending the percpu portion of block core stats, and then do an incremental to clean it all up. But I'm open to doing it however you'd like if you feel strongly about how this should be done. Mike