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 S1759963AbcJRKrn (ORCPT <rfc822;w@1wt.eu>);
        Tue, 18 Oct 2016 06:47:43 -0400
Received: from Galois.linutronix.de ([146.0.238.70]:40626 "EHLO
        Galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1759651AbcJRKre (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Tue, 18 Oct 2016 06:47:34 -0400
Date: Tue, 18 Oct 2016 12:44:47 +0200 (CEST)
From: Thomas Gleixner <tglx@linutronix.de>
To: "Luck, Tony" <tony.luck@intel.com>
cc: Fenghua Yu <fenghua.yu@intel.com>,
        "H. Peter Anvin" <h.peter.anvin@intel.com>,
        Ingo Molnar <mingo@elte.hu>, Peter Zijlstra <peterz@infradead.org>,
        Stephane Eranian <eranian@google.com>, Borislav Petkov <bp@suse.de>,
        Dave Hansen <dave.hansen@intel.com>,
        Nilay Vaish <nilayvaish@gmail.com>, Shaohua Li <shli@fb.com>,
        David Carrillo-Cisneros <davidcc@google.com>,
        Ravi V Shankar <ravi.v.shankar@intel.com>,
        Sai Prakhya <sai.praneeth.prakhya@intel.com>,
        Vikas Shivappa <vikas.shivappa@linux.intel.com>,
        linux-kernel <linux-kernel@vger.kernel.org>, x86 <x86@kernel.org>
Subject: Re: [PATCH v4 13/18] x86/intel_rdt: Add mkdir to resctrl file
 system
In-Reply-To: <20161017233729.GA6386@intel.com>
Message-ID: <alpine.DEB.2.20.1610181237080.4824@nanos>
References: <1476497548-11169-1-git-send-email-fenghua.yu@intel.com> <1476497548-11169-14-git-send-email-fenghua.yu@intel.com> <alpine.DEB.2.20.1610172157360.6407@nanos> <20161018011845.GD8999@linux.intel.com> <alpine.DEB.2.20.1610180103330.6407@nanos>
 <20161017233729.GA6386@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, 17 Oct 2016, Luck, Tony wrote:
> On Tue, Oct 18, 2016 at 01:20:36AM +0200, Thomas Gleixner wrote:
> > It's certainly not perfect (missing L2 etc.), but clearly avoids exactly
> > the above issues. And it would allow you to utilize the 256 groups in an
> > understandable way.
> 
> If you head down that path someone with a 4-socket system will try to
> make 16x16x16x16 = 65536 groups and "understandable" takes a bit of
> a beating. The eight socket system with 16^8 = 4G groups defies any
> rationale hope. Best not to think about 16 sockets.
> 
> The L2 + L3 configuration space gets unbelievably messy too.
> 
> There's a reason why I ripped out the allocation code and went with
> a simple global allocator in this version.  If we decide we need something
> fancier we can adapt later. Some solutions might be transparent to
> applications, others might add a "closid" file into each directory to
> give 2nd generation applications hooks to view (and maybe control)
> which closid is used by each group.

I'm not saying that we want something fancier. I fully agree with your
decision to make a simple global allocator.

I was just puzzled by the 16*16 comment and wondered what this is
about. Looking at Fenghuas explanation and the examples there is nothing
which really looks like we ever want it. In fact the fancy CLOSID matrix
does not make much sense at all.

So I rather would like to see a comment clearly explaining why the chosen
allocator (grouping) gives us the most straight forward way to utilize the
hardware. It surely restricts the theoretical choices, but it limits them to
the subset which makes technically sense.

Thanks,

	tglx