Date: Fri, 27 Feb 2015 14:42:04 -0500
From: Tejun Heo <tj@kernel.org>
To: Vikas Shivappa <vikas.shivappa@intel.com>
Cc: Vikas Shivappa <vikas.shivappa@linux.intel.com>,
        linux-kernel@vger.kernel.org, matt.fleming@intel.com, hpa@zytor.com,
        tglx@linutronix.de, mingo@kernel.org, peterz@infradead.org,
        will.auld@intel.com, dave.hansen@intel.com, andi.kleen@intel.com,
        tony.luck@intel.com, kanaka.d.juvva@intel.com
Subject: Re: [PATCH 3/7] x86/intel_rdt: Support cache bit mask for Intel CAT
Message-ID: <20150227194204.GP3964@htj.duckdns.org>
References: <1424819804-4082-1-git-send-email-vikas.shivappa@linux.intel.com>
 <1424819804-4082-4-git-send-email-vikas.shivappa@linux.intel.com>
 <20150227121222.GE3964@htj.duckdns.org>
 <alpine.DEB.2.10.1502271118040.31647@vshiva-Udesk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <alpine.DEB.2.10.1502271118040.31647@vshiva-Udesk>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2038
Lines: 49

Hello, Vikas.

On Fri, Feb 27, 2015 at 11:34:16AM -0800, Vikas Shivappa wrote:
> This cgroup subsystem would basically let the user partition one of the
> Platform shared resource , the LLC cache. This could be extended in future

I suppose LLC means last level cache?  It'd be great if you can spell
out the full term when the abbreviation is first referenced in the
comments or documentation.

> to partition more shared resources when there is hardware support that way
> we may eventually have more files in the cgroup. RDT is a generic term for
> platform resource sharing.

> For more information you can refer to section 17.15 of Intel SDM.
> We did go through quite a bit of discussion on lkml regarding adding the
> cgroup interface for CAT and the patches were posted only after that.
> This cgroup would not interact with other cgroups in the sense would not
> modify or add any elements to existing cgroups - there was such a proposal
> but was removed as we did not get agreement on lkml.
>
> the original lkml thread is here from 10/2014 for your reference -
> https://lkml.org/lkml/2014/10/16/568

Yeap, I followed that thread and this being a separate controller
definitely makes a lot more sense.

>   I
> >take it that the feature implemented is too coarse to allow for weight
> >based distribution?
> >
> Could you please clarify more on this ? However there is a limitation from
> hardware that there have to be a minimum of 2 bits in the cbm if thats what
> you referred to. Otherwise the bits in the cbm directly map to the number of
> cache ways and hence the cache capacity ..

Right, so the granularity is fairly coarse and specifying things like
"distribute cache in 4:2:1 (or even in absolute bytes) to these three
cgroups" wouldn't work at all.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/