The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Reinette Chatre <reinette.chatre@intel.com>
To: Borislav Petkov <bp@alien8.de>
Cc: "Moger, Babu" <bmoger@amd.com>, Ben Horgan <ben.horgan@arm.com>,
	<linux-kernel@vger.kernel.org>, <tony.luck@intel.com>,
	<Dave.Martin@arm.com>, <james.morse@arm.com>,
	<babu.moger@amd.com>, <tglx@kernel.org>, <mingo@redhat.com>,
	<dave.hansen@linux.intel.com>, <x86@kernel.org>, <hpa@zytor.com>,
	<fenghuay@nvidia.com>, <tan.shaopeng@fujitsu.com>
Subject: Re: [PATCH v7 0/7] x86,fs/resctrl: Pave the way for MPAM counter assignment
Date: Wed, 6 May 2026 10:06:34 -0700	[thread overview]
Message-ID: <84b0bfde-37ec-4160-82d6-49ec1618ff67@intel.com> (raw)
In-Reply-To: <20260506165601.GEaftyoXxuP5qXBk9T@fat_crate.local>

Hi Boris,

On 5/6/26 9:56 AM, Borislav Petkov wrote:
> On Wed, May 06, 2026 at 08:58:07AM -0700, Reinette Chatre wrote:
>> Ben is not rushing this work and has indeed been patiently addressing feedback.
>> I considered this series to indeed be close to ready during the previous
>> cycle but instead of rushing the polishing was left for this cycle.
>>
>> v7 closely followed v6 since we felt v6 was ready for inclusion but contained
>> an unfortunate typo (missing a "---" in changelog). v7 was thus submitted shortly to
>> ensure we pass a clean series to x86 maintainers for consideration.
> 
> Yap, I saw all that.
> 
>> This is an instance where a brand new reviewer appears to a series after all patches have
>> RB tag. I welcome and appreciate all reviews and it would be great to see more such
>> collaboration to general resctrl and earlier in review cycles. In this case I do not
>> believe this criticism about this work being half-baked and rushed is justified.
> 
> I think you're misunderstanding me. My response was to Babu in an attempt to
> correct his thinking that somehow patches should be rushed before a merge
> window.

I did misunderstand. My apologies.

> 
> People tend to do that in front of merge windows and I'm replying to that
> sentiment in the hope that as many people as possible read that and understand
> that rushing patches never works and is never good.

ack.

> 
> It didn't have anything to do with Ben's patchset - it *just* happened to be
> on that thread only.
> 
> As a matter of fact, I started applying his v7 but was waiting for Sashiko to
> finish reviewing it.

Thank you very much for considering this series.

> 
> I hope this makes the whole thing more clear.

It does. Thank you very much.

Reinette


  reply	other threads:[~2026-05-06 17:06 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-06  8:28 [PATCH v7 0/7] x86,fs/resctrl: Pave the way for MPAM counter assignment Ben Horgan
2026-05-06  8:28 ` [PATCH v7 1/7] fs/resctrl: Tidy up the error path in resctrl_mkdir_event_configs() Ben Horgan
2026-05-06 15:05   ` Moger, Babu
2026-05-07 14:26     ` Borislav Petkov
2026-05-06  8:28 ` [PATCH v7 2/7] x86,fs/resctrl: Create 'event_filter' files read only if they're not configurable Ben Horgan
2026-05-06  8:28 ` [PATCH v7 3/7] fs/resctrl: Disallow the software controller when MBM counters are assignable Ben Horgan
2026-05-06  8:28 ` [PATCH v7 4/7] fs/resctrl: Add monitor property 'mbm_cntr_assign_fixed' Ben Horgan
2026-05-06  8:28 ` [PATCH v7 5/7] fs/resctrl: Continue counter allocation after failure Ben Horgan
2026-05-06  8:28 ` [PATCH v7 6/7] fs/resctrl: Document that automatic counter assignment is best effort Ben Horgan
2026-05-06  8:28 ` [PATCH v7 7/7] fs/resctrl: Document tasks file behaviour for task id 0 and idle tasks Ben Horgan
2026-05-06 15:01 ` [PATCH v7 0/7] x86,fs/resctrl: Pave the way for MPAM counter assignment Moger, Babu
2026-05-06 15:08   ` Ben Horgan
2026-05-06 15:28   ` Borislav Petkov
2026-05-06 15:58     ` Reinette Chatre
2026-05-06 16:56       ` Borislav Petkov
2026-05-06 17:06         ` Reinette Chatre [this message]
2026-05-06 18:33           ` Borislav Petkov

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=84b0bfde-37ec-4160-82d6-49ec1618ff67@intel.com \
    --to=reinette.chatre@intel.com \
    --cc=Dave.Martin@arm.com \
    --cc=babu.moger@amd.com \
    --cc=ben.horgan@arm.com \
    --cc=bmoger@amd.com \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=fenghuay@nvidia.com \
    --cc=hpa@zytor.com \
    --cc=james.morse@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=tan.shaopeng@fujitsu.com \
    --cc=tglx@kernel.org \
    --cc=tony.luck@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox