lkml.org 
[lkml]   [2015]   [Nov]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [RFD] CAT user space interface revisited
Date
+Tony

> -----Original Message-----
> From: Luiz Capitulino [mailto:lcapitulino@redhat.com]
> Sent: Wednesday, November 18, 2015 11:38 AM
> To: Thomas Gleixner
> Cc: LKML; Peter Zijlstra; x86@kernel.org; Marcelo Tosatti; Shivappa, Vikas; Tejun
> Heo; Yu, Fenghua; Auld, Will; Dugger, Donald D; riel@redhat.com
> Subject: Re: [RFD] CAT user space interface revisited
>
> On Wed, 18 Nov 2015 19:25:03 +0100 (CET) Thomas Gleixner
> <tglx@linutronix.de> wrote:
>
> > We really need to make this as configurable as possible from userspace
> > without imposing random restrictions to it. I played around with it on
> > my new intel toy and the restriction to 16 COS ids (that's 8 with CDP
> > enabled) makes it really useless if we force the ids to have the same
> > meaning on all sockets and restrict it to per task partitioning.
> >
> > Even if next generation systems will have more COS ids available,
> > there are not going to be enough to have a system wide consistent view
> > unless we have COS ids > nr_cpus.
> >
> > Aside of that I don't think that a system wide consistent view is
> > useful at all.
>
> This is a great writeup! I agree with everything you said.
>
> > So now to the interface part. Unfortunately we need to expose this
> > very close to the hardware implementation as there are really no
> > abstractions which allow us to express the various bitmap
> > combinations. Any abstraction I tried to come up with renders that
> > thing completely useless.
> >
> > I was not able to identify any existing infrastructure where this
> > really fits in. I chose a directory/file based representation. We
> > certainly could do the same with a syscall, but that's just an
> > implementation detail.
> >
> > At top level:
> >
> > xxxxxxx/cat/max_cosids <- Assume that all CPUs are the same
> > xxxxxxx/cat/max_maskbits <- Assume that all CPUs are the same
> > xxxxxxx/cat/cdp_enable <- Depends on CDP availability
> >
> > Per socket data:
> >
> > xxxxxxx/cat/socket-0/
> > ...
> > xxxxxxx/cat/socket-N/l3_size
> > xxxxxxx/cat/socket-N/hwsharedbits
> >
> > Per socket mask data:
> >
> > xxxxxxx/cat/socket-N/cos-id-0/
> > ...
> > xxxxxxx/cat/socket-N/cos-id-N/inuse
> > /cat_mask
> > /cdp_mask <- Data mask if CDP enabled
> >
> > Per cpu default cos id for the cpus on that socket:
> >
> > xxxxxxx/cat/socket-N/cpu-x/default_cosid
> > ...
> > xxxxxxx/cat/socket-N/cpu-N/default_cosid
> >
> > The above allows a simple cpu based partitioning. All tasks which do
> > not have a cache partition assigned on a particular socket use the
> > default one of the cpu they are running on.
> >
> > Now for the task(s) partitioning:
> >
> > xxxxxxx/cat/partitions/
> >
> > Under that directory one can create partitions
> >
> > xxxxxxx/cat/partitions/p1/tasks
> > /socket-0/cosid
> > ...
> > /socket-n/cosid
> >
> > The default value for the per socket cosid is COSID_DEFAULT, which
> > causes the task(s) to use the per cpu default id.
>
> I hope I've got all the details right, but this proposal looks awesome.
> There's more people who seem to agree with something like this.
>
> Btw, I think it should be possible to implement this with cgroups. But I too don't
> care that much on cgroups vs. syscalls.


\
 
 \ /
  Last update: 2015-11-18 21:01    [W:0.184 / U:1.680 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site