[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <41cd71514a9042abaaef909d816e2522@AcuMS.aculab.com>
Date: Thu, 27 Jun 2019 09:12:40 +0000
From: David Laight <David.Laight@...LAB.COM>
To: 'Reinette Chatre' <reinette.chatre@...el.com>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"fenghua.yu@...el.com" <fenghua.yu@...el.com>,
"bp@...en8.de" <bp@...en8.de>,
"tony.luck@...el.com" <tony.luck@...el.com>
CC: "mingo@...hat.com" <mingo@...hat.com>,
"hpa@...or.com" <hpa@...or.com>, "x86@...nel.org" <x86@...nel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH 00/10] x86/CPU and x86/resctrl: Support pseudo-lock
regions spanning L2 and L3 cache
From: Reinette Chatre
> Sent: 26 June 2019 18:49
>
> Cache pseudo-locking involves preloading a region of physical memory into a
> reserved portion of cache that no task or CPU can subsequently fill into and
> from that point on will only serve cache hits. At this time it is only
> possible to create cache pseudo-locked regions in either L2 or L3 cache,
> supporting systems that support either L2 Cache Allocation Technology (CAT)
> or L3 CAT because CAT is the mechanism used to manage reservations of cache
> portions.
While this is a 'nice' hardware feature for some kinds of embedded systems
I don't see how it can be sensibly used inside a Linux kernel.
There are an awful lot of places where things can go horribly wrong.
I can imagine:
- Multiple requests to lock regions that end up trying to use the same
set-associative cache lines leaving none for normal operation.
- Excessive cache line bouncing because fewer lines are available.
- The effect of cache invalidate requests for the locked addresses.
- I suspect the Linux kernel can do full cache invalidates at certain times.
You've not given a use case.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
Powered by blists - more mailing lists