Re: [RFD] CAT user space interface revisited

[Thomas Gleixner]

On Wed, 18 Nov 2015, Marcelo Tosatti wrote:
> On Wed, Nov 18, 2015 at 07:25:03PM +0100, Thomas Gleixner wrote:
> > 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.
> 
> No you don't.

Because you have a use case which allows you to write some policy
translator? I seriously doubt that it is general enough.
 
> Again: you don't need to look into the MSR table and relate it 
> to tasks if you store the data as:
> 
> 	task group 1 = {
> 			reservation-1 = {size = 80Kb, type = data, socketmask = 0xffff},
> 			reservation-2 = {size = 100Kb, type = code, socketmask = 0xffff}
> 	}
> 	
> 	task group 2 = {
> 			reservation-1 = {size = 80Kb, type = data, socketmask = 0xffff},
> 			reservation-3 = {size = 200Kb, type = code, socketmask = 0xffff}
> 	}
> 
> Task group 1 and task group 2 share reservation-1.
> 
> This is what userspace is going to expose to users, of course.


 
> If you expose the MSRs to userspace, you force userspace to convert
> from this format to the MSRs (minding whether there
> are contiguous regions available, and the region shared with HW).

Fair enough. I'm not too fond about the exposure of the MSRs, but I
chose this just to explain the full problem space and the various
requirements we might have accross the full application space.

If we can come up with an abstract way which does not impose
restrictions on the overall configuration abilities, I'm all for it.

>     - The bits which select a cache partition need to be consecutive
> 
> BUT, for our usecase the cgroups interface works as well, so lets
> go with that (Tejun apparently had a usecase where tasks were allowed to 
> set reservations themselves, on response to external events).

Can you please set aside your narrow use case view for a moment and
just think about the full application space? We are not designing such
an interface for a single use case.

Thanks,

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