2006-10-16 19:07:10

by Lu, Yinghai

[permalink] [raw]
Subject: [PATCH] x86_64: store Socket ID in phys_proc_id

Current code store phys_proc_id with init APIC ID, and later will change
to apicid>>bits.

So for the apic id lifted system, for example BSP with apicid 0x10, the
phys_proc_id will be 8.

This patch use initial APIC ID to get Socket ID.

It also removed ht_nodeid calculating, because We already have correct
socket id for sure.

Signed-off-by: Yinghai Lu <[email protected]>



Attachments:
setup_c.diff (2.15 kB)
setup_c.diff

2006-10-17 15:34:50

by Lu, Yinghai

[permalink] [raw]
Subject: Re: [PATCH] x86_64: store Socket ID in phys_proc_id

Current code store phys_proc_id with init APIC ID, and later will change
to apicid>>bits.

So for the apic id lifted system, for example BSP with apicid 0x10, the
phys_proc_id will be 8.

This patch use initial APIC ID to get Socket ID.

It also removed ht_nodeid calculating, because We already have correct
socket id for sure.

Signed-off-by: Yinghai Lu <[email protected]>


Attachments:
(No filename) (377.00 B)
setup_c.diff (2.15 kB)
Download all attachments

2006-10-17 17:53:11

by Andi Kleen

[permalink] [raw]
Subject: Re: [PATCH] x86_64: store Socket ID in phys_proc_id

On Tue, Oct 17, 2006 at 08:34:47AM -0700, Yinghai Lu wrote:
> Current code store phys_proc_id with init APIC ID, and later will change
> to apicid>>bits.
>
> So for the apic id lifted system, for example BSP with apicid 0x10, the
> phys_proc_id will be 8.

How is that a problem?


> This patch use initial APIC ID to get Socket ID.
>
> It also removed ht_nodeid calculating, because We already have correct
> socket id for sure.

we've had cases where it wasn't identical, that is when i originally
added that code.

-Andi

2006-10-17 19:40:59

by Lu, Yinghai

[permalink] [raw]
Subject: RE: [PATCH] x86_64: store Socket ID in phys_proc_id

From: Andi Kleen [mailto:[email protected]]

>> So for the apic id lifted system, for example BSP with apicid 0x10,
the
>> phys_proc_id will be 8.

>How is that a problem?

Socket ID is 0 for first Physical processor?

>> It also removed ht_nodeid calculating, because We already have
correct
>> socket id for sure.

>we've had cases where it wasn't identical, that is when i originally
>added that code.

OK, it must be system with Horus?

YH


2006-10-17 20:58:44

by Andi Kleen

[permalink] [raw]
Subject: Re: [PATCH] x86_64: store Socket ID in phys_proc_id

On Tue, Oct 17, 2006 at 11:26:30AM -0700, Lu, Yinghai wrote:
> From: Andi Kleen [mailto:[email protected]]
>
> >> So for the apic id lifted system, for example BSP with apicid 0x10,
> the
> >> phys_proc_id will be 8.
>
> >How is that a problem?
>
> Socket ID is 0 for first Physical processor?

It must just be some unique ID for each socket.

> >> It also removed ht_nodeid calculating, because We already have
> correct
> >> socket id for sure.
>
> >we've had cases where it wasn't identical, that is when i originally
> >added that code.
>
> OK, it must be system with Horus?

No it was with some dual core systems. Not all systems follow
the standard convention. Also there can be missing memory on
some nodes, this code handles this too.

-Andi

2006-10-17 21:16:57

by Lu, Yinghai

[permalink] [raw]
Subject: RE: [PATCH] x86_64: store Socket ID in phys_proc_id

From: Andi Kleen [mailto:[email protected]]

>> Socket ID is 0 for first Physical processor?
>It must just be some unique ID for each socket.

For dual core, if I lift AP's APIC ID and no touch BSP's APIC ID.
For example, BSP is still 0, and second core is 0x11.
The phys_proc_id will be 0 for BSP, and 8 for second core.
So I suggest you to use initial APIC ID to get socket id instead of APIC
ID.

YH


2006-10-18 13:04:48

by Andi Kleen

[permalink] [raw]
Subject: Re: [PATCH] x86_64: store Socket ID in phys_proc_id

On Tue, Oct 17, 2006 at 02:15:38PM -0700, Lu, Yinghai wrote:
> From: Andi Kleen [mailto:[email protected]]
>
> >> Socket ID is 0 for first Physical processor?
> >It must just be some unique ID for each socket.
>
> For dual core, if I lift AP's APIC ID and no touch BSP's APIC ID.
> For example, BSP is still 0, and second core is 0x11.
> The phys_proc_id will be 0 for BSP, and 8 for second core.
> So I suggest you to use initial APIC ID to get socket id instead of APIC
> ID.

Hmm, that might make sense yes.

I'm just afraid what I will break again if i touch this -- it took several
iterations to get it to this state which AFAIK works everywhere right now.
And when it breaks it's usually subtle as "system boots, but runs
slower when ACPI is turned off because NUMA nodes are off"

Can you remind me again what would be fixed by using the initial APIC ID?
Just prettier numbering in your lifted APIC IDs case? Or something
else too?

-Andi

2006-10-18 17:15:29

by Lu, Yinghai

[permalink] [raw]
Subject: RE: [PATCH] x86_64: store Socket ID in phys_proc_id

From: Andi Kleen [mailto:[email protected]]

>Can you remind me again what would be fixed by using the initial APIC
ID?
>Just prettier numbering in your lifted APIC IDs case? Or something
>else too?

For easier understanding for socket id and apic id mapping. Also doesn't
care about BIOS how to set the APIC ID.

YH