[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <874jg9rh7k.fsf@rasp.cworth.amperemail.amperecomputing.com>
Date: Fri, 22 Dec 2023 14:43:43 -0800
From: Carl Worth <carl@...amperecomputing.com>
To: James Morse <james.morse@....com>, x86@...nel.org,
linux-kernel@...r.kernel.org
Cc: Fenghua Yu <fenghua.yu@...el.com>, Reinette Chatre
<reinette.chatre@...el.com>, Thomas Gleixner <tglx@...utronix.de>, Ingo
Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>, H Peter Anvin
<hpa@...or.com>, Babu Moger <Babu.Moger@....com>, James Morse
<james.morse@....com>, shameerali.kolothum.thodi@...wei.com, D Scott
Phillips OS <scott@...amperecomputing.com>, lcherian@...vell.com,
bobo.shaobowang@...wei.com, tan.shaopeng@...itsu.com,
baolin.wang@...ux.alibaba.com, Jamie Iles <quic_jiles@...cinc.com>, Xin
Hao <xhao@...ux.alibaba.com>, peternewman@...gle.com,
dfustini@...libre.com, amitsinght@...vell.com
Subject: Re: [PATCH v8 00/24] x86/resctrl: monitored closid+rmid together,
separate arch/fs locking
James Morse <james.morse@....com> writes:
> This series does two things, it changes resctrl to call resctrl_arch_rmid_read()
> in a way that works for MPAM, and it separates the locking so that the arch code
> and filesystem code don't have to share a mutex. I tried to split this as two
> series, but these touch similar call sites, so it would create more work.
>
> (What's MPAM? See the cover letter of the first series. [1])
Thanks, James. This is really useful for us at Ampere since it enables
the MPAM driver on top of this series.
I've tested this series on an Ampere implementation, by successfully
using resctrl to configure and exercise MPAM functionality. I can't
speak to the effects of the refactor on x86 since I have not tested that
all.
For the series:
Tested-by: Carl Worth <carl@...amperecomputing.com>
-Carl
Powered by blists - more mailing lists