Received: by 2002:a05:6a10:c7c6:0:0:0:0 with SMTP id h6csp2858340pxy; Tue, 3 Aug 2021 17:50:26 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyN+TeKn/PLIXBJDioslWyi6ZzWPz7DKX8YLwBVWd95QF71Cv1jf210vV2fnkV7QcCs1XnP X-Received: by 2002:a05:6e02:1bc7:: with SMTP id x7mr3142399ilv.116.1628038226678; Tue, 03 Aug 2021 17:50:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1628038226; cv=none; d=google.com; s=arc-20160816; b=vvW5/E7Ey2XdVZtlW2NE6SuOm9TacGjYL/Dt0uwCvze2Na350cznDbwfT+pbfBvmEG GJMiXFv2MxxKs7wm6qHt2PjdRvZNsjmSY3/AwU5VumBhHCLe+YD0pVfldf7YvqHR5c7U 2vImdA0Bsyg0orLBFzgIZivXStWJR5nEmbYgWWVtgdX8ASSBi8Kf4zLePp7T3LTE+No/ p941ZVEbZ/M/1944SxbfI+GmvnXUk27bAfj8NlnhTROR0TYZLZ1E29h+EGdbGOjKbEzm ocLDoI3lUzSjduFscNAoKOgfgAVG9VUyPf3qRWNJhsgQQp+jppfn7KooZmAKYRxS1IxU M/7g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:references :in-reply-to:subject:cc:to:dkim-signature:dkim-signature:from; bh=uXPzQ106Gzz/QfQUvV21NZBY82K/Xa1WUotPKxNKs/s=; b=0iD61QPQ91y9s59nc6yJhFN2yEKYGUQFZXgpu+CFHrfn7RPrqnwEX0JZCEwdW9rEDH 92u90VZeNfkFEGqxSdsFYZT1psGXZnyH+zMHcow0VhZUiJNmLfSJVvrRzd9abU2CtkKI EyUe3PELHnQYy+qdLwAwN9jRDjmgNvcalH7wBP2DV6+JDQprdwc6s5n4HXdq088SgZ2e Fxjasr34erxmwergCeT3DCGM5uEh/9GBvB71D+cNbjkkGd/E7T+JobVJ9ZaB9pJs+B7s ZI+6usek3dERbZeGdwUIuH902Wv6A6u1ZruyWp/PKMvhMYIU/Svt4c7fwFfd8oH3o2FH So/A== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@linutronix.de header.s=2020 header.b=g2tVyGLV; dkim=neutral (no key) header.i=@linutronix.de header.b=ZHq7Hf3i; 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=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id az34si551693jab.63.2021.08.03.17.50.13; Tue, 03 Aug 2021 17:50:26 -0700 (PDT) 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=fail header.i=@linutronix.de header.s=2020 header.b=g2tVyGLV; dkim=neutral (no key) header.i=@linutronix.de header.b=ZHq7Hf3i; 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=fail (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234721AbhHCXzB (ORCPT + 99 others); Tue, 3 Aug 2021 19:55:01 -0400 Received: from Galois.linutronix.de ([193.142.43.55]:60438 "EHLO galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233784AbhHCXzB (ORCPT ); Tue, 3 Aug 2021 19:55:01 -0400 From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1628034888; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=uXPzQ106Gzz/QfQUvV21NZBY82K/Xa1WUotPKxNKs/s=; b=g2tVyGLVgyvvt51y4phFCb4e/IRo+TkCrR0P7rBCXrlqqV0FKAVjAnQJdSyb3vhaHN1GmM JWSCfIw6Z9h71HVqL2Fd4i8fs59RyB65mscfupaiU1TtrZDpqx3291G6iYN3YYjdcB612K kI/o+QLxBFdJZICfP3jZdqsMg89RjInVaGpfpF/JObzZDzA4zvMVZtaCB1dE5rrFiOP1xF Nxv2UQEayZUGtfN2y6y5P/vjiQq5C5KmuFshIrlqWHrLBchL/6WfwSceA6k0dw2XmFQ7jq Ws+K18sAjWTdCQXhV73P9SYp3dTLo8YxiEVUOfXDtxbs8Il6oHwvbssnPGYTBQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1628034888; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=uXPzQ106Gzz/QfQUvV21NZBY82K/Xa1WUotPKxNKs/s=; b=ZHq7Hf3ihfyizoxoVi0V4ONzM+2F6n6diNdxjaMuOUZ9CkkB7CtkKmdUo9JFoivEPz8Nhv K7baBhsWJ/AmalCw== To: Mel Gorman , Andrew Morton Cc: Ingo Molnar , Vlastimil Babka , Hugh Dickins , Linux-MM , Linux-RT-Users , LKML , Mel Gorman , Peter Zijlstra Subject: Re: [PATCH 2/2] mm/vmstat: Protect per cpu variables with preempt disable on RT In-Reply-To: <20210723100034.13353-3-mgorman@techsingularity.net> References: <20210723100034.13353-1-mgorman@techsingularity.net> <20210723100034.13353-3-mgorman@techsingularity.net> Date: Wed, 04 Aug 2021 01:54:47 +0200 Message-ID: <87czqu2iew.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Mel! On Fri, Jul 23 2021 at 11:00, Mel Gorman wrote: > From: Ingo Molnar > > Disable preemption on -RT for the vmstat code. On vanila the code runs > in IRQ-off regions while on -RT it may not when stats are updated under > a local_lock. "preempt_disable" ensures that the same resources is not > updated in parallel due to preemption. > > This patch differs from the preempt-rt version where __count_vm_event and > __count_vm_events are also protected. The counters are explicitly "allowed > to be to be racy" so there is no need to protect them from preemption. Only > the accurate page stats that are updated by a read-modify-write need > protection. > > Signed-off-by: Ingo Molnar > Signed-off-by: Thomas Gleixner > Signed-off-by: Mel Gorman > --- > mm/vmstat.c | 12 ++++++++++++ > 1 file changed, 12 insertions(+) > > diff --git a/mm/vmstat.c b/mm/vmstat.c > index b0534e068166..d06332c221b1 100644 > --- a/mm/vmstat.c > +++ b/mm/vmstat.c > @@ -319,6 +319,7 @@ void __mod_zone_page_state(struct zone *zone, enum zone_stat_item item, > long x; > long t; > > + preempt_disable_rt(); Yes, this is smart to some extent. But in reality it's a bandaid simply because nobody can tell which item of vmstat requires which protection. If you go back in RT history then you will figure out that we were able to eliminate _all_ occurences of preempt_disable_rt() except for this one. Even mm developers are wary about this: so in vmstat.c there is this magic comment: * For use when we know that interrupts are disabled * or when we know that preemption is disabled and that * particular counter cannot be updated from interrupt context. how can I know which counters need what? I don't think there's a list, one would have to check on counter to counter basis :/ and of course there is nothing which validates that, right? exactly Brilliant stuff which prevents you to do any validation on this. Over the years there have been several issues where callers had to be fixed by analysing bug reports instead of having a proper instrumentation in that code which would have told the developer that he got it wrong. Of course on RT kernels the preempt_disable_rt() will serialize everything correctly, but as we have learned over the years just slapping _if_rt() or if_not_rt() variants of things around is most of the time papering over the underlying problem of badly defined protection scopes. Let's not proliferate that. As I said in the above IRC conversation: I fundamentally hate this preempt_disable_rt() muck Thanks, tglx