From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751888AbdFTU2f (ORCPT ); Tue, 20 Jun 2017 16:28:35 -0400 Received: from mx2.suse.de ([195.135.220.15]:60930 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751002AbdFTU2e (ORCPT ); Tue, 20 Jun 2017 16:28:34 -0400 Subject: Re: [PATCH v2 2/2] writeback: Rework wb_[dec|inc]_stat family of functions To: Tejun Heo Cc: jbacik@fb.com, linux-kernel@vger.kernel.org, mgorman@techsingularity.net References: <20170620173346.GB21326@htj.duckdns.org> <1497981720-7036-1-git-send-email-nborisov@suse.com> <20170620193715.GF21326@htj.duckdns.org> From: Nikolay Borisov Message-ID: <274063e4-57d0-5a87-1f43-28f5232af52b@suse.com> Date: Tue, 20 Jun 2017 23:28:30 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <20170620193715.GF21326@htj.duckdns.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 20.06.2017 22:37, Tejun Heo wrote: > Hello, Nikolay. > > On Tue, Jun 20, 2017 at 09:02:00PM +0300, Nikolay Borisov wrote: >> Currently the writeback statistics code uses a percpu counters to hold >> various statistics. Furthermore we have 2 families of functions - those which >> disable local irq and those which doesn't and whose names begin with >> double underscore. However, they both end up calling __add_wb_stats which in >> turn calls percpu_counter_add_batch which is already irq-safe. > > Heh, looks like I was confused. __percpu_counter_add() is not > irq-safe. It disables preemption and uses __this_cpu_read(), so > there's no protection against irq. If writeback statistics want > irq-safe operations and it does, it would need these separate > operations. Am I missing something? So looking at the history of the commit initially there was preempt_disable + this_cpu_ptr which was later changed in: 819a72af8d66 ("percpucounter: Optimize __percpu_counter_add a bit through the use of this_cpu() options.") I believe that having __this_cpu_read ensures that we get an atomic snapshot of the variable but when we are doing the actual write e.g. the else {} branch we actually use this_cpu_add which ought to be preempt + irq safe, meaning we won't get torn write. In essence we have atomic reads by merit of __this_cpu_read + atomic writes by merit of using raw_spin_lock_irqsave in the if() branch and this_cpu_add in the else {} branch. > > Thanks. >