Re: [PATCH v5 6/9] ACPI/PPTT: Add topology parsing code

[Rafael J. Wysocki]

On Thu, Dec 14, 2017 at 12:06 AM, Jeremy Linton <jeremy.linton@xxxxxxx> wrote:
> Hi,
>
>
> On 12/13/2017 04:28 PM, Rafael J. Wysocki wrote:
>>
>> On Wed, Dec 13, 2017 at 6:38 PM, Lorenzo Pieralisi
>> <lorenzo.pieralisi@xxxxxxx> wrote:
>>>
>>> On Tue, Dec 12, 2017 at 10:13:08AM -0600, Jeremy Linton wrote:
>>>>
>>>> Hi,
>>>>
>>>> First, thanks for taking a look at this.
>>>>
>>>> On 12/11/2017 07:12 PM, Rafael J. Wysocki wrote:
>>>>>
>>>>> On Friday, December 1, 2017 11:23:27 PM CET Jeremy Linton wrote:
>>>>>>
>>>>>> The PPTT can be used to determine the groupings of CPU's at
>>>>>> given levels in the system. Lets add a few routines to the PPTT
>>>>>> parsing code to return a unique id for each unique level in the
>>>>>> processor hierarchy. This can then be matched to build
>>>>>> thread/core/cluster/die/package/etc mappings for each processing
>>>>>> element in the system.
>>>>>>
>>>>>> Signed-off-by: Jeremy Linton <jeremy.linton@xxxxxxx>
>>>>>
>>>>>
>>>>> Why can't this be folded into patch [2/9]?
>>>>
>>>>
>>>> It can, and I will be happy squash it.
>>>>
>>>> It was requested that the topology portion of the parser be split
>>>> out back in v3.
>>>>
>>>> https://www.spinics.net/lists/linux-acpi/msg78487.html
>>>
>>>
>>> I asked to split cache/topology since I am not familiar with cache
>>> code and Sudeep - who looks after the cache code - won't be able
>>> to review this series in time for v4.16.
>>
>>
>> OK, so why do we need it in 4.16?
>
>
> I think its more case of as soon as possible. That is because there are
> machines where the topology is completely incorrect due to assumptions the
> kernel makes based on registers that aren't defined for that purpose (say
> describing which cores are in a physical socket, or LLC's attached to
> interconnects or memory controllers).
>
> This incorrect topology information is reported to things like the kernel
> scheduler, which then makes poor scheduling decisions resulting in
> sub-optimal system performance.
>
> This patchset (and ACPI 6.2) clears up a lot of those problems.

As long as the ACPI tables are as expected that is, I suppose?

Anyway, fair enough, but I don't want to rush it in.

Thanks,
Rafael