From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S933393AbdGKPWa (ORCPT <rfc822;w@1wt.eu>);
        Tue, 11 Jul 2017 11:22:30 -0400
Received: from Galois.linutronix.de ([146.0.238.70]:44716 "EHLO
        Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S932229AbdGKPW3 (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 11 Jul 2017 11:22:29 -0400
Date: Tue, 11 Jul 2017 17:22:18 +0200 (CEST)
From: Thomas Gleixner <tglx@linutronix.de>
To: "Luck, Tony" <tony.luck@intel.com>
cc: Shivappa Vikas <vikas.shivappa@intel.com>,
        Vikas Shivappa <vikas.shivappa@linux.intel.com>, x86@kernel.org,
        linux-kernel@vger.kernel.org, hpa@zytor.com, peterz@infradead.org,
        ravi.v.shankar@intel.com, fenghua.yu@intel.com, andi.kleen@intel.com
Subject: Re: [PATCH 21/21] x86/intel_rdt/mbm: Handle counter overflow
In-Reply-To: <20170710175418.ghphbgunhswrravh@intel.com>
Message-ID: <alpine.DEB.2.20.1707111721250.1799@nanos>
References: <1498503368-20173-1-git-send-email-vikas.shivappa@linux.intel.com> <1498503368-20173-22-git-send-email-vikas.shivappa@linux.intel.com> <alpine.DEB.2.20.1707021548460.2296@nanos> <alpine.DEB.2.10.1707061651540.3798@vshiva-Udesk>
 <alpine.DEB.2.20.1707070849430.1871@nanos> <20170710175418.ghphbgunhswrravh@intel.com>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Mon, 10 Jul 2017, Luck, Tony wrote:
> On Fri, Jul 07, 2017 at 08:50:40AM +0200, Thomas Gleixner wrote:
> > Aside of that, are you really serious about serializing the world and
> > everything on a single global mutex?
> 
> It would be nice to not do that, but there are challenges. At
> any instant someone else might run:
> 
> # rmdir /sys/fs/resctrl/{some_control_group}
> 
> and blow away the control group and all the monitor groups under
> it.
> 
> Someone else might do:
> 
> # echo 0 > /sys/devices/system/cpu/cpu{N}/online
> 
> where "N" is the last online cpu in a domain, which will
> blow away an rdt_domain structure and ask kernfs to remove
> some monitor files from every monitor directory.
> 
> 
> If we change how we handle rdt_domains to
> 
> 1) Not delete them when last CPU goes away (and re-use them
>    if they come back)
> 2) Have a safe way to search rdt_resource.domains for a domain
>    that we know is there even though another may be in the middle
>    of being added
> 
> Then we could probably make:
> 
> $ cat /sys/fs/restrl/ ... /llc_occupancy
> 
> etc. not need to grab the mutex.  We'd still need something
> to protect against a cross processor interrupt geting in the
> middle of the access to IA32_QM_EVTSEL/IA32_QM_CTR and for
> MBM counters to serialize access to mbm_state ... but it would
> be a lot finer granularity.

Thanks for the explanation. Yes, that would be nice, but we can start off
with the global mutex and think about the scalability issue after we got
the functionality itself under control.

Thanks,

	tglx