From: Reinette Chatre <reinette.chatre@intel.com>
To: Dave Hansen <dave.hansen@intel.com>,
"Luck, Tony" <tony.luck@intel.com>,
"Chen, Yu C" <yu.c.chen@intel.com>
Cc: "tglx@kernel.org" <tglx@kernel.org>,
"bp@alien8.de" <bp@alien8.de>,
"mingo@redhat.com" <mingo@redhat.com>,
"dave.hansen@linux.intel.com" <dave.hansen@linux.intel.com>,
"hpa@zytor.com" <hpa@zytor.com>,
"fenghuay@nvidia.com" <fenghuay@nvidia.com>,
"babu.moger@amd.com" <babu.moger@amd.com>,
"chen.yu@linux.dev" <chen.yu@linux.dev>,
"x86@kernel.org" <x86@kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v6 2/9] x86/resctrl: Require 64-bit x86 for resctrl support
Date: Thu, 20 Aug 2026 10:48:45 -0700 [thread overview]
Message-ID: <c517ff5c-ed8e-4177-a5aa-186e5c9aca5d@intel.com> (raw)
In-Reply-To: <bd252483-fb0a-4818-bfaf-b9b6ebd187fe@intel.com>
On 8/20/26 10:12 AM, Dave Hansen wrote:
> On 8/20/26 10:01, Luck, Tony wrote:
>>> To be specific, my comment about RDT not being a "server" feature was made with Apollo
>>> Lake [1] in mind. That system showed up in scenarios where servers do not typically venture
>>> and per [1] its max memory size (8GB) is significantly less than what servers can support.
>> Even with just 8GB you should really use 64-bit.
>
> Just in practice, 32-bit is very lightly tested. We're generally not
> even supporting new CPU features on 32-bit even if the hardware supports
> it. Think of shadow stacks, for instance.
>
> It's actually increasingly hard to even find a modern 32-bit distro.
>
> So it really has nothing to do with high memory. It just practically
> that the arch/x86 32-bit code is increasingly there for legacy reasons.
> Its testing goes down every day and the testing of *new* features is for
> all intents and purposes zero.
>
> Honestly, the only people who complain about 32-bit support going away
> are folks who "test" it regularly. It's quite rare to see anyone
> actually "using" a 32-bit system.
I do support this change and clearly stated so in my original review [1].
My comments were only regarding accuracy of the motivation used in the
changelog.
Reinette
[1] https://lore.kernel.org/lkml/d97deaa1-f42c-4fce-8ca8-5ccf8d822cd2@intel.com/
next prev parent reply other threads:[~2026-08-20 17:48 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-25 9:20 [PATCH v6 0/9] Introduce MMIO-based CMT access for Enhanced RDT Chen Yu
2026-07-25 9:22 ` [PATCH v6 1/9] x86/topology: Export topo_lookup_cpuid() for resctrl use Chen Yu
2026-08-19 22:55 ` Reinette Chatre
2026-08-22 4:16 ` Chen Yu
2026-07-25 9:22 ` [PATCH v6 2/9] x86/resctrl: Require 64-bit x86 for resctrl support Chen Yu
2026-08-19 22:55 ` Reinette Chatre
2026-08-20 15:20 ` Luck, Tony
2026-08-20 15:54 ` Reinette Chatre
2026-08-20 17:01 ` Luck, Tony
2026-08-20 17:12 ` Dave Hansen
2026-08-20 17:48 ` Reinette Chatre [this message]
2026-08-21 2:37 ` Borislav Petkov
2026-08-21 15:47 ` Reinette Chatre
2026-08-21 15:54 ` Borislav Petkov
2026-08-21 11:28 ` Peter Zijlstra
2026-08-21 15:52 ` Borislav Petkov
2026-08-21 16:58 ` Luck, Tony
2026-08-22 0:04 ` Borislav Petkov
2026-07-25 9:22 ` [PATCH v6 3/9] x86/resctrl: Parse ACPI ERDT table and save CACD cpumask for RMDD domains Chen Yu
2026-08-19 23:01 ` Reinette Chatre
2026-07-25 9:23 ` [PATCH v6 4/9] x86/resctrl: Attach ACPI ERDT information to L3 mon domain on CPU online Chen Yu
2026-08-19 23:04 ` Reinette Chatre
2026-07-25 9:23 ` [PATCH v6 5/9] x86/resctrl: Parse ACPI CMRC table Chen Yu
2026-08-19 23:06 ` Reinette Chatre
2026-07-25 9:23 ` [PATCH v6 6/9] x86/resctrl: Refactor the monitor read function Chen Yu
2026-08-19 23:07 ` Reinette Chatre
2026-07-25 9:23 ` [PATCH v6 7/9] fs/resctrl: Do not invoke smp_processor_id() in preemptible context Chen Yu
2026-08-19 23:08 ` Reinette Chatre
2026-07-25 9:23 ` [PATCH v6 8/9] x86/resctrl: Introduce erdt_cpu_has() and erdt_support() Chen Yu
2026-08-19 23:08 ` Reinette Chatre
2026-07-25 9:23 ` [PATCH v6 9/9] x86/resctrl: Add MMIO-based LLC occupancy monitoring support Chen Yu
2026-08-19 23:10 ` Reinette Chatre
2026-08-13 6:43 ` [PATCH v6 0/9] Introduce MMIO-based CMT access for Enhanced RDT Chen Yu
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=c517ff5c-ed8e-4177-a5aa-186e5c9aca5d@intel.com \
--to=reinette.chatre@intel.com \
--cc=babu.moger@amd.com \
--cc=bp@alien8.de \
--cc=chen.yu@linux.dev \
--cc=dave.hansen@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=fenghuay@nvidia.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@kernel.org \
--cc=tony.luck@intel.com \
--cc=x86@kernel.org \
--cc=yu.c.chen@intel.com \
/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.