Messages in this thread | | | From | Peter Newman <> | Date | Thu, 23 Mar 2023 10:09:07 +0100 | Subject | Re: [PATCH v3 09/19] x86/resctrl: Queue mon_event_read() instead of sending an IPI |
| |
On Wed, Mar 22, 2023 at 3:07 PM Peter Newman <peternewman@google.com> wrote: > On Mon, Mar 20, 2023 at 6:27 PM James Morse <james.morse@arm.com> wrote: > > > > x86 is blessed with an abundance of monitors, one per RMID, that can be > > As I explained earlier, this is not the case on AMD. > > > read from any CPU in the domain. MPAMs monitors reside in the MMIO MSC, > > the number implemented is up to the manufacturer. This means when there are > > fewer monitors than needed, they need to be allocated and freed. > > > > Worse, the domain may be broken up into slices, and the MMIO accesses > > for each slice may need performing from different CPUs. > > > > These two details mean MPAMs monitor code needs to be able to sleep, and > > IPI another CPU in the domain to read from a resource that has been sliced. > > This doesn't sound very convincing. Could mon_event_read() IPI all the > CPUs in the domain? (after waiting to allocate and install monitors > when necessary?)
No wait, I know that isn't correct.
As you explained it, the remote CPU needs to sleep because it may need to atomically acquire, install, and read a CSU monitor.
It still seems possible for the mon_event_read() thread to do all the waiting (tell remote CPU to program CSU monitor, wait, tell same remote CPU to read monitor), but that sounds like more work that I don't see a lot of benefit to doing today.
Can you update the changelog to just say the remote CPU needs to block when installing a CSU monitor?
Thanks! -Peter
| |