All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephane Eranian <eranian@google.com>
To: Fenghua Yu <fenghua.yu@intel.com>
Cc: Reinette Chatre <reinette.chatre@intel.com>,
	linux-kernel@vger.kernel.org, babu.moger@amd.com, x86@kernel.org
Subject: Re: [PATCH v2] x86/resctrl: Fix zero cbm for AMD in cbm_validate
Date: Wed, 25 May 2022 16:10:30 +0300	[thread overview]
Message-ID: <CABPqkBTU_StuH_zyZ=22wtV5_V8YDnxRpTSjy4Bg0s=mk8PahQ@mail.gmail.com> (raw)
In-Reply-To: <YoUgKB5svdI/blZa@fyu1.sc.intel.com>

On Wed, May 18, 2022 at 7:36 PM Fenghua Yu <fenghua.yu@intel.com> wrote:
>
> Hi, Babu,
>
> On Tue, May 17, 2022 at 11:10:40AM -0700, Reinette Chatre wrote:
> > On 5/17/2022 10:27 AM, Fenghua Yu wrote:
> > > On Tue, May 17, 2022 at 09:49:22AM -0700, Reinette Chatre wrote:
> > >> On 5/17/2022 9:33 AM, Fenghua Yu wrote:
> > >>> On Mon, May 16, 2022 at 05:12:34PM -0700, Stephane Eranian wrote:
> > >>>> AMD supports cbm with no bits set as reflected in rdt_init_res_defs_amd() by:
> > >>> ...
> > >>>> @@ -107,6 +107,10 @@ static bool cbm_validate(char *buf, u32 *data, struct rdt_resource *r)
> > >>>>          first_bit = find_first_bit(&val, cbm_len);
> > >>>>          zero_bit = find_next_zero_bit(&val, cbm_len, first_bit);
> > >>>>
> > >>>> +        /* no need to check bits if arch supports no bits set */
> > >>>> +        if (r->cache.arch_has_empty_bitmaps && val == 0)
> > >>>> +                goto done;
> > >>>> +
> > >>>>          /* Are non-contiguous bitmaps allowed? */
> > >>>>          if (!r->cache.arch_has_sparse_bitmaps &&
> > >>>>              (find_next_bit(&val, cbm_len, zero_bit) < cbm_len)) {
> > >>>> @@ -119,7 +123,7 @@ static bool cbm_validate(char *buf, u32 *data, struct rdt_resource *r)
> > >>>>                                      r->cache.min_cbm_bits);
> > >>>>                  return false;
> > >>>>          }
> > >>>> -
> > >>>> +done:
> > >>>>          *data = val;
> > >>>>          return true;
> > >>>>  }
> > >>>
> > >>> Isn't it AMD supports 0 minimal CBM bits? Then should set its min_cbm_bits as 0.
> > >>> Is the following patch a better fix? I don't have AMD machine and cannot
> > >>> test the patch.
> > >>>
> > >>> diff --git a/arch/x86/kernel/cpu/resctrl/core.c b/arch/x86/kernel/cpu/resctrl/core.c
> > >>> index 6055d05af4cc..031d77dd982d 100644
> > >>> --- a/arch/x86/kernel/cpu/resctrl/core.c
> > >>> +++ b/arch/x86/kernel/cpu/resctrl/core.c
> > >>> @@ -909,6 +909,7 @@ static __init void rdt_init_res_defs_amd(void)
> > >>>                   r->cache.arch_has_sparse_bitmaps = true;
> > >>>                   r->cache.arch_has_empty_bitmaps = true;
> > >>>                   r->cache.arch_has_per_cpu_cfg = true;
> > >>> +                 r->cache.min_cbm_bits = 0;
> > >>>           } else if (r->rid == RDT_RESOURCE_MBA) {
> > >>>                   hw_res->msr_base = MSR_IA32_MBA_BW_BASE;
> > >>>                   hw_res->msr_update = mba_wrmsr_amd;
> > >>
> > >> That is actually what Stephane's V1 [1] did and I proposed that
> > >> he fixes it with (almost) what he has in V2 (I think the check
> > >> can be moved earlier before any bits are searched for).
> > >>
> > >> The reasons why I proposed this change are:
> > >> - min_cbm_bits is a value that is exposed to user space and from the
> > >>   time AMD was supported this has always been 1 for those systems. I
> > >>   do not know how user space uses this value and unless I can be certain
> > >>   making this 0 will not affect user space I would prefer not to
> > >>   make such a change.
> > >
> > > But a user visible mismatch is created by the V2 patch:
> >
> > No. V2 does not create a user visible change, it restores original behavior.
> >
> > > User queries min_cbm_bits and finds it is 1 but turns out 0 can be written
> > > to the schemata.
> > >
> > > Is it an acceptable behavior? Shouldn't user read right min_cbm_bits (0)
> > > on AMD?
> >
> > Original AMD enabling set min_cbm_bits as 1 while also supporting 0 to
> > be written to schemata file. Supporting 0 to be written to schemata file
> > was unintentionally broken during one of the MPAM prep patches. This
> > patch fixes that.
> >
> > You are proposing a change to original AMD support that impacts user
> > space API while I find fixing to restore original behavior to
> > be the safest option. Perhaps Babu could pick the preferred solution
> > and I would step aside if you prefer to go with (an improved) V1.
>
> Is it OK for you to set min_cbm_bits to 0 on AMD?
>
I agree with Fenghua here. The proper fix is my v1 which sets the
min_cbm_bits to the value it should have set to from the beginning.
This field is exposed via resctrl fs and it is still fine if the value
changes. Any app is supposed to read the content of the file and not
hardcode
any value or pre-suppose it is always 1.

  reply	other threads:[~2022-05-25 13:10 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-17  0:12 [PATCH v2] x86/resctrl: Fix zero cbm for AMD in cbm_validate Stephane Eranian
2022-05-17 16:33 ` Fenghua Yu
2022-05-17 16:49   ` Reinette Chatre
2022-05-17 17:27     ` Fenghua Yu
2022-05-17 18:10       ` Reinette Chatre
2022-05-18 16:34         ` Fenghua Yu
2022-05-25 13:10           ` Stephane Eranian [this message]
2022-07-25 19:47             ` Babu Moger
2022-08-01 14:58               ` Moger, Babu
2022-08-01 15:19                 ` Stephane Eranian
2022-10-18 18:33 ` [tip: x86/urgent] x86/resctrl: Fix min_cbm_bits for AMD tip-bot2 for Babu Moger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CABPqkBTU_StuH_zyZ=22wtV5_V8YDnxRpTSjy4Bg0s=mk8PahQ@mail.gmail.com' \
    --to=eranian@google.com \
    --cc=babu.moger@amd.com \
    --cc=fenghua.yu@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=reinette.chatre@intel.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.