public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* [PATCH 0/3] ACPI SRAT: Disregard reserved PXM bits
@ 2012-01-15 21:30 Kurt Garloff
  2012-01-15 21:34 ` [PATCH 1/3]: Store SRAT revision Kurt Garloff
                   ` (2 more replies)
  0 siblings, 3 replies; 8+ messages in thread
From: Kurt Garloff @ 2012-01-15 21:30 UTC (permalink / raw)
  To: linux-kernel, linux-acpi; +Cc: stable, Len Brown

[-- Attachment #1: Type: text/plain, Size: 2196 bytes --]

Hi,

this has been submitted thrice already -- and while it found a bit of
friendly feedback, it has not been merged. It should be IMVHO, and I
hope this time the right eyes see this flying by ...
I should mention that it fixes a real problem (wrong affinities reported
in sysfs and thus userspace high-perf compute code taking wrong
decisions) and that this has been part of SUSE enterprise kernels since 
a few years now.
It should also go right into stable IMVHO.

Original description to follow ...


ACPI specification says that the OS must disregard reserved bits.
The x86_64 SRAT parser does not discard the upper 24 bits of the
proximity_domain (pxm) in the acpi_srat_mem_affinity entries for
SRAT v1 tables. (v2 has 32 bits wide fields, v1 only 8 bits.)
This can lead to problems with poor BIOS implementations that failed
to set reserved bytes to zero. (The ACPI spec is a bit vague here
unfortunately.)

This was also inconsistent: On x86-64 (srat_64.c), the 
_cpu_affinity does only use the low 8 bits of pxm, while the
full 32 bits of _mem_affinity are consumed.
In srat_32.c (x86), only 8bits are used (which is OK, a 32bit system
with >256 PXMs does not seem reasonable at all).
On ia64, the support of more than 8 bits was consistent between
mem and cpu affinity entries, however it was dependent on "sn2" 
platform.

The patch series has the following goals:
* Make the kernel support consistently 8bits or 32bits for the
  proximity domain
* Make this dependent on the SRAT version; v1 => 8bits, v2 => 32bits.

Overview over the patches:
- [1/3] Store the SRAT table version value in acpi_srat_revision 
- [2/3] x86-64: Discard the upper 24 bits in mem_affinity if rev <= 1
        and use upper 24bits in cpu_affinity if rev >= 2
- [3/3] ia64: Also use upper 8/24bits if rev >= 2 (but leave logic to
        enable on sn2 as well -- I don't know if sn2 reports v1 or v2
        SRAT) Also add two __init decls in ia64 pxm accessors.

Patch is against current git.

Note: If you respond to this mail, please keep me in Cc -- I'm not
subscribed to LKML these days.

Cheers,
-- 
Kurt Garloff <kurt@garloff.de>  [Koeln/Greven]


[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

^ permalink raw reply	[flat|nested] 8+ messages in thread
* [PATCH 0/3]: Discard reserved PXM bits for SRAT v1
@ 2009-05-18  9:33 Kurt Garloff
  2009-05-18  9:46 ` [PATCH 1/3]: Store SRAT revision Kurt Garloff
  0 siblings, 1 reply; 8+ messages in thread
From: Kurt Garloff @ 2009-05-18  9:33 UTC (permalink / raw)
  To: Linux kernel list
  Cc: Norbert Eicker, Greg Kroah-Hartman, Alexey Starikovskiy,
	Len Brown

[-- Attachment #1: Type: text/plain, Size: 1776 bytes --]

Hi,

ACPI specification says that the OS must disregard reserved bits.
The x86_64 SRAT parser does not discard the upper 24 bits of the
proximity_domain (pxm) in the acpi_srat_mem_affinity entries for
SRAT v1 tables. (v2 has 32 bits wide fields.)
This can lead to problems with poor BIOS implementations that failed
to set resreved bytes to zero. (The ACPI spec is a bit vague here
unfortunately.)

This was also inconsistent: On x86-64 (srat_64.c), the 
_cpu_affinity does only use the low 8 bits of pxm, while the
full 32 bits of _mem_affinity are consumed.
In srat_32.c (x86), only 8bits are used (which is OK, a 32bit system
with >256 PXMs does not seem reasonable at all).
On ia64, the support of more than 8 bits was consistent between
mem and cpu affinity entries, however it dependent on "sn2" platform.

The patch series has the following goals:
* Make the kernel support consistently 8bits or 32bits for the
  proximity domain
* Make this dependent on the SRAT version; v1 => 8bits, v2 => 32bits.

Overview over the patches:
- [1/3] Store the SRAT table version value in acpi_srat_revision 
- [2/3] x86-64: Discard the upper 24 bits in mem_affinity if rev <= 1
        and use upper 24bits in cpu_affinity if rev >= 2
- [3/3] ia64: Also use upper 8/24bits if rev >= 2 (but leave logic to
        enable on sn2 as well -- I don't know if sn2 reports v1 or v2
        SRAT) Also add two __init decls in ia64 pxm accessors.

Patch has been tested on x86-64 against an 2.6.27.x kernel.
(Patch is against current git.)

Thanks for James, Greg, Alexey, Norbert for comments, review and testing.

Please review and apply!

Greg, I believe this is a candidate for -stable.
-- 
Kurt Garloff, VP OPS Partner Engineering -- Novell Inc.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 8+ messages in thread
end of thread, other threads:[~2012-01-17 13:20 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-01-15 21:30 [PATCH 0/3] ACPI SRAT: Disregard reserved PXM bits Kurt Garloff
2012-01-15 21:34 ` [PATCH 1/3]: Store SRAT revision Kurt Garloff
2012-01-15 21:52   ` Greg KH
2012-01-17  9:24   ` Len Brown
2012-01-17 13:20     ` Kurt Garloff
2012-01-15 21:36 ` [PATCH 2/3]: x86-64: Handle SRAT v1 and v2 consistently Kurt Garloff
2012-01-15 21:37 ` [PATCH 3/3]: Consider SRAT rev on ia64 Kurt Garloff
  -- strict thread matches above, loose matches on Subject: below --
2009-05-18  9:33 [PATCH 0/3]: Discard reserved PXM bits for SRAT v1 Kurt Garloff
2009-05-18  9:46 ` [PATCH 1/3]: Store SRAT revision Kurt Garloff

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox