RE: [RFC PATCH 00/20] Intel(R) Resource Director Technology Cache Pseudo-Locking enabling

[Thomas Gleixner]

On Mon, 15 Jan 2018, Hindman, Gavin wrote:
> > From: linux-kernel-owner@xxxxxxxxxxxxxxx [mailto:linux-kernel-
> > owner@xxxxxxxxxxxxxxx] On Behalf Of Thomas Gleixner
> > On Fri, 17 Nov 2017, Reinette Chatre wrote:
> > >
> > > 1) PALLOC is not upstream and while inquiring about the status of this
> > > work (please see https://github.com/heechul/palloc/issues/4 for
> > > details) we learned that one reason for this is that recent Intel
> > > processors are not well supported.
> > 
> > So if I understand Heechul correctly then recent CPUs cannot be supported
> > easily due to changes in the memory controllers and the cache. I assume the
> > latter is related to CAT.

Is that assumption correct?

> > > 2) The most recent kernel supported by PALLOC is v4.4 and also
> > > mentioned in the above link there is currently no plan to upstream
> > > this work for a less divergent comparison of PALLOC and the more
> > > recent RDT/CAT enabling on which Cache Pseudo-Locking is built.
> > 
> > Well, that's not a really good excuse for not trying. You at Intel should be able
> > to get to the parameters easy enough :)
> >
> We can run the comparison, but I'm not sure that I understand the intent
> - my understanding of Palloc is that it's intended to allow allocation of
> memory to specific physical memory banks.  While that might result in
> reduced cache-misses since processes are more separated, it's not
> explicitly intended to reduce cache-misses, and Palloc's benefits would
> only hold as long as you have few enough processes to be able to
> dedicate/isolate memory accordingly.  Am I misunderstanding the
> intent/usage of palloc?

Right. It comes with its own set of restrictions as does the pseudo-locking.

> > > >> The cache pseudo-locking approach relies on generation-specific
> > > >> behavior of processors. It may provide benefits on certain
> > > >> processor generations, but is not guaranteed to be supported in the
> > future.
> > > >
> > > > Hmm, are you saying that the CAT mechanism might change radically in
> > > > the future so that access to cached data in an allocated area which
> > > > does not belong to the current executing context wont work anymore?
> > >
> 
> No, I don't see any scenario in which devices that currently support
> pseudo-locking would stop working, but until support is architectural
> support in a current generation of a product line doesn't imply support
> in a future generation.  Certainly we'll make every effort to carry
> support forward, and would adjust to any changes in CAT support, but we
> can't account for unforeseen future architectural changes that might
> block pseudo-locking use-cases on top of CAT.

So and that's the real problem. We add something which gives us some form
of isolation, but we don't know whether next generation CPUs will
work. From a maintainability and usefulnes POV that's not a really great
prospect.

> > This is again a marketing pitch and not answering my question about real
> > world use cases.
> > 
> There are a number of real-world use-cases that are already making use of
> hacked-up ad-hoc versions of pseudo-locking - this corner case has been
> available in hardware for some time - and this patch-set is intended to
> bring it more into the mainstream and more supportable.  Primary usages
> right now are industrial PLCs/automation and high-frequency
> trading/financial enterprise systems, but anything with relatively small
> repeating data structures should see benefit.

Ok,

> > > > what are those applications supposed to do once the feature breaks
> > > > with future generations of processors?
> > >
> > > This feature is model specific with a few platforms supporting it at
> > > this time. Only platforms known to support Cache Pseudo-Locking will
> > > expose its resctrl interface.
> > 
> > And you deliberately avoided to answer my question again.
> >
> Reinette's not trying to avoid the questions, we just don't necessarily
> have definitive answers at this time.  Currently pseudo-locking requires
> manual setup on the part of the integrator, so there will not be any
> invisible breakage when trying to port software expecting pseudo-locking
> to new devices, and we'll certainly do everything we can to minimize
> user-space/configuration impact on migration if things change going
> forward, but these are unknowns.  We are in a bit of chicken/egg where
> people aren't broadly using it because it's not architectural, and it's
> not architectural because people aren't broadly using it.  We could
> publicly carry the patches out of mainline, but our intent for pushing
> the patches to mainline are to a) increase exposure/usage b) reduce
> divergence across people already using hacked versions, and c) ease the
> overhead in keep patches in sync with the larger CAT infrastructure as it
> evolves - we are clear on the potential support burden being incurred by
> submitting a non-architectural feature, and there's certainly no intent
> to dump a science-experiment into mainline.

Ok. So what you are saying is that 'official' support should broaden the
user base which in turn might push it into the architectural realm.

I'll go through the patch set with this in mind.

Thanks,

	tglx