Re: [PATCH] x86: add PCI IDs to k8topology_64.c II
On Tue, 29 Jan 2008, Andi Kleen wrote: > > SRAT is essentially just a two dimensional table with node distances. > > Sorry, that was actually SLIT. SRAT is not two dimensional, but also > relatively simple. SLIT you don't really need to implement. yeah but i'd heartily recommend implementing SLIT too. mind you it's almost universal non-existence means i've had to resort to userland measurements to determine node distances and that won't change. i guess i just wanted to grumble somewhere. -dean -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: add PCI IDs to k8topology_64.c II
On Tue, 29 Jan 2008, Andi Kleen wrote: SRAT is essentially just a two dimensional table with node distances. Sorry, that was actually SLIT. SRAT is not two dimensional, but also relatively simple. SLIT you don't really need to implement. yeah but i'd heartily recommend implementing SLIT too. mind you it's almost universal non-existence means i've had to resort to userland measurements to determine node distances and that won't change. i guess i just wanted to grumble somewhere. -dean -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: add PCI IDs to k8topology_64.c II
On Jan 29, 2008 12:31 AM, Andi Kleen <[EMAIL PROTECTED]> wrote: > > On Mon, Jan 28, 2008 at 11:39:30PM -0800, Yinghai Lu wrote: > > On Jan 29, 2008 12:09 AM, Andi Kleen <[EMAIL PROTECTED]> wrote: > > > > SRAT is essentially just a two dimensional table with node distances. > > > > > > Sorry, that was actually SLIT. SRAT is not two dimensional, but also > > > relatively simple. SLIT you don't really need to implement. > > > > > > > need to add some CONFIG option to parse SRAT, MADT etc only. but don't > > pull DSDT related... > > I don't think it needs a CONFIG. The code should handle this case > by itself in any case. I'm not entirely sure it does currently, but if it > doesn't it will likely not be very difficult to fix. > > Or are you worried about code size? ACPI is around ~270k on x86-64, > which while certainly not small should not be a problem on x86 NUMA > systems. like acpi=off, acpi=tableonly? so it will load dsdt, and some one module rely on dsdt could not complain ACPI ERROR.. YH -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: add PCI IDs to k8topology_64.c II
On Jan 29, 2008 12:31 AM, Andi Kleen [EMAIL PROTECTED] wrote: On Mon, Jan 28, 2008 at 11:39:30PM -0800, Yinghai Lu wrote: On Jan 29, 2008 12:09 AM, Andi Kleen [EMAIL PROTECTED] wrote: SRAT is essentially just a two dimensional table with node distances. Sorry, that was actually SLIT. SRAT is not two dimensional, but also relatively simple. SLIT you don't really need to implement. need to add some CONFIG option to parse SRAT, MADT etc only. but don't pull DSDT related... I don't think it needs a CONFIG. The code should handle this case by itself in any case. I'm not entirely sure it does currently, but if it doesn't it will likely not be very difficult to fix. Or are you worried about code size? ACPI is around ~270k on x86-64, which while certainly not small should not be a problem on x86 NUMA systems. like acpi=off, acpi=tableonly? so it will load dsdt, and some one module rely on dsdt could not complain ACPI ERROR.. YH -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: add PCI IDs to k8topology_64.c II
On Mon, Jan 28, 2008 at 11:39:30PM -0800, Yinghai Lu wrote: > On Jan 29, 2008 12:09 AM, Andi Kleen <[EMAIL PROTECTED]> wrote: > > > SRAT is essentially just a two dimensional table with node distances. > > > > Sorry, that was actually SLIT. SRAT is not two dimensional, but also > > relatively simple. SLIT you don't really need to implement. > > > > need to add some CONFIG option to parse SRAT, MADT etc only. but don't > pull DSDT related... I don't think it needs a CONFIG. The code should handle this case by itself in any case. I'm not entirely sure it does currently, but if it doesn't it will likely not be very difficult to fix. Or are you worried about code size? ACPI is around ~270k on x86-64, which while certainly not small should not be a problem on x86 NUMA systems. -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: add PCI IDs to k8topology_64.c II
On Jan 29, 2008 12:09 AM, Andi Kleen <[EMAIL PROTECTED]> wrote: > > SRAT is essentially just a two dimensional table with node distances. > > Sorry, that was actually SLIT. SRAT is not two dimensional, but also > relatively simple. SLIT you don't really need to implement. > need to add some CONFIG option to parse SRAT, MADT etc only. but don't pull DSDT related... YH -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: add PCI IDs to k8topology_64.c II
> SRAT is essentially just a two dimensional table with node distances. Sorry, that was actually SLIT. SRAT is not two dimensional, but also relatively simple. SLIT you don't really need to implement. -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: add PCI IDs to k8topology_64.c
Andi Kleen wrote: also there are some users are using LinuxBIOS or other firmware that doesn't have or like ACPI support. but they still need numa. for them ACPI doesn't help. We've had this discussion before. The right way even if you don't want to do full ACPI is to do just the minimal static boot tables and a SRAT. These are quite simple tables and should be easy to set up. SRAT is essentially just a two dimensional table with node distances. Indeed. Hacking everything into the kernel just because LinuxBIOS is braindead is NOT a good idea. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: add PCI IDs to k8topology_64.c
> also there are some users are using LinuxBIOS or other firmware that doesn't > have or like ACPI support. but they still need numa. > for them ACPI doesn't help. We've had this discussion before. The right way even if you don't want to do full ACPI is to do just the minimal static boot tables and a SRAT. These are quite simple tables and should be easy to set up. SRAT is essentially just a two dimensional table with node distances. -Andi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: add PCI IDs to k8topology_64.c
On Monday 28 January 2008 07:48:06 pm Andi Kleen wrote: > "Joachim Deguara" <[EMAIL PROTECTED]> writes: > > > Quick history, this is a harmless patch that got dropped by Andi as a mixup > > to > > It's not harmless. > > > dropping another patch of mine that was made obsolete by Yinghai. > > http://thread.gmane.org/gmane.linux.kernel/559581 > > No that's not the correct history. The correct history is that > I intentionally rejected this patch because the old k8topology > hack should really not be used anymore on modern machines (especially > not on Quad Cores). SRAT is the far better way to handle this problem > because it has a proper abstraction. > > The problem with k8topology.c is that it needs to know very low level > information (like HT node numbers etc.) the kernel should not really > need to know and which are difficult to handle generally without > motherboard specific knowledge. > > k8topology.c mostly guesses, which was never a good way to handle this. > Also in in the various "node has no memory" cases it needs quite > hackish fallback heuristics which will be always fragile. Then there > are some ugly interactions with quad cores. And some other issues > > I still think the patch a bad idea because adapting this file all > the time is a long term maintenance issue. I can say that as > the original author :-) It was just a quick hack long ago > to get NUMA going early. But now it far outlived its usefulness > and adapting it to modern machines is the wrong direction. > > Best is to phase k8topology out. then with acpi=off, we can not use numa any more. also there are some users are using LinuxBIOS or other firmware that doesn't have or like ACPI support. but they still need numa. for them ACPI doesn't help. YH -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: add PCI IDs to k8topology_64.c
"Joachim Deguara" <[EMAIL PROTECTED]> writes: > Quick history, this is a harmless patch that got dropped by Andi as a mixup > to It's not harmless. > dropping another patch of mine that was made obsolete by Yinghai. > http://thread.gmane.org/gmane.linux.kernel/559581 No that's not the correct history. The correct history is that I intentionally rejected this patch because the old k8topology hack should really not be used anymore on modern machines (especially not on Quad Cores). SRAT is the far better way to handle this problem because it has a proper abstraction. The problem with k8topology.c is that it needs to know very low level information (like HT node numbers etc.) the kernel should not really need to know and which are difficult to handle generally without motherboard specific knowledge. k8topology.c mostly guesses, which was never a good way to handle this. Also in in the various "node has no memory" cases it needs quite hackish fallback heuristics which will be always fragile. Then there are some ugly interactions with quad cores. And some other issues I still think the patch a bad idea because adapting this file all the time is a long term maintenance issue. I can say that as the original author :-) It was just a quick hack long ago to get NUMA going early. But now it far outlived its usefulness and adapting it to modern machines is the wrong direction. Best is to phase k8topology out. -Andi > > -Joachim > > -- > > x86: add PCI IDs to k8topology_64.c > > This just adds the PCI IDs of AMD's family 10h and 11h CPU's northbridges > to > k8topology discovery. > > Signed-off-by: Joachim Deguara <[EMAIL PROTECTED]> > Signed-off-by: Andi Kleen <[EMAIL PROTECTED]> > Acked-by: Yinghai Lu <[EMAIL PROTECTED]> > > diff --git a/arch/x86/mm/k8topology_64.c b/arch/x86/mm/k8topology_64.c > index a96006f..b123ea3 100644 > --- a/arch/x86/mm/k8topology_64.c > +++ b/arch/x86/mm/k8topology_64.c > @@ -28,11 +28,15 @@ static __init int find_northbridge(void) > u32 header; > > header = read_pci_config(0, num, 0, 0x00); > - if (header != (PCI_VENDOR_ID_AMD | (0x1100<<16))) > + if (header != (PCI_VENDOR_ID_AMD | (0x1100<<16)) && > + header != (PCI_VENDOR_ID_AMD | (0x1200<<16)) && > + header != (PCI_VENDOR_ID_AMD | (0x1300<<16))) > continue; > > header = read_pci_config(0, num, 1, 0x00); > - if (header != (PCI_VENDOR_ID_AMD | (0x1101<<16))) > + if (header != (PCI_VENDOR_ID_AMD | (0x1101<<16)) && > + header != (PCI_VENDOR_ID_AMD | (0x1201<<16)) && > + header != (PCI_VENDOR_ID_AMD | (0x1301<<16))) > continue; > return num; > } -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: add PCI IDs to k8topology_64.c
On Monday 28 January 2008 12:54:41 pm Ingo Molnar wrote: > > * Joachim Deguara <[EMAIL PROTECTED]> wrote: > > > x86: add PCI IDs to k8topology_64.c > > > > This just adds the PCI IDs of AMD's family 10h and 11h CPU's > > northbridges to k8topology discovery. > > thanks Joachim, applied. thanks. I used it with my local patches for supporting family 10h with acpi=off pci=nomsi for a while. YH -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: add PCI IDs to k8topology_64.c
* Joachim Deguara <[EMAIL PROTECTED]> wrote: > x86: add PCI IDs to k8topology_64.c > > This just adds the PCI IDs of AMD's family 10h and 11h CPU's > northbridges to k8topology discovery. thanks Joachim, applied. Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: add PCI IDs to k8topology_64.c
On Monday 28 January 2008 12:54:41 pm Ingo Molnar wrote: * Joachim Deguara [EMAIL PROTECTED] wrote: x86: add PCI IDs to k8topology_64.c This just adds the PCI IDs of AMD's family 10h and 11h CPU's northbridges to k8topology discovery. thanks Joachim, applied. thanks. I used it with my local patches for supporting family 10h with acpi=off pci=nomsi for a while. YH -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: add PCI IDs to k8topology_64.c
* Joachim Deguara [EMAIL PROTECTED] wrote: x86: add PCI IDs to k8topology_64.c This just adds the PCI IDs of AMD's family 10h and 11h CPU's northbridges to k8topology discovery. thanks Joachim, applied. Ingo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: add PCI IDs to k8topology_64.c
Joachim Deguara [EMAIL PROTECTED] writes: Quick history, this is a harmless patch that got dropped by Andi as a mixup to It's not harmless. dropping another patch of mine that was made obsolete by Yinghai. http://thread.gmane.org/gmane.linux.kernel/559581 No that's not the correct history. The correct history is that I intentionally rejected this patch because the old k8topology hack should really not be used anymore on modern machines (especially not on Quad Cores). SRAT is the far better way to handle this problem because it has a proper abstraction. The problem with k8topology.c is that it needs to know very low level information (like HT node numbers etc.) the kernel should not really need to know and which are difficult to handle generally without motherboard specific knowledge. k8topology.c mostly guesses, which was never a good way to handle this. Also in in the various node has no memory cases it needs quite hackish fallback heuristics which will be always fragile. Then there are some ugly interactions with quad cores. And some other issues I still think the patch a bad idea because adapting this file all the time is a long term maintenance issue. I can say that as the original author :-) It was just a quick hack long ago to get NUMA going early. But now it far outlived its usefulness and adapting it to modern machines is the wrong direction. Best is to phase k8topology out. -Andi -Joachim -- x86: add PCI IDs to k8topology_64.c This just adds the PCI IDs of AMD's family 10h and 11h CPU's northbridges to k8topology discovery. Signed-off-by: Joachim Deguara [EMAIL PROTECTED] Signed-off-by: Andi Kleen [EMAIL PROTECTED] Acked-by: Yinghai Lu [EMAIL PROTECTED] diff --git a/arch/x86/mm/k8topology_64.c b/arch/x86/mm/k8topology_64.c index a96006f..b123ea3 100644 --- a/arch/x86/mm/k8topology_64.c +++ b/arch/x86/mm/k8topology_64.c @@ -28,11 +28,15 @@ static __init int find_northbridge(void) u32 header; header = read_pci_config(0, num, 0, 0x00); - if (header != (PCI_VENDOR_ID_AMD | (0x110016))) + if (header != (PCI_VENDOR_ID_AMD | (0x110016)) + header != (PCI_VENDOR_ID_AMD | (0x120016)) + header != (PCI_VENDOR_ID_AMD | (0x130016))) continue; header = read_pci_config(0, num, 1, 0x00); - if (header != (PCI_VENDOR_ID_AMD | (0x110116))) + if (header != (PCI_VENDOR_ID_AMD | (0x110116)) + header != (PCI_VENDOR_ID_AMD | (0x120116)) + header != (PCI_VENDOR_ID_AMD | (0x130116))) continue; return num; } -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: add PCI IDs to k8topology_64.c
On Monday 28 January 2008 07:48:06 pm Andi Kleen wrote: Joachim Deguara [EMAIL PROTECTED] writes: Quick history, this is a harmless patch that got dropped by Andi as a mixup to It's not harmless. dropping another patch of mine that was made obsolete by Yinghai. http://thread.gmane.org/gmane.linux.kernel/559581 No that's not the correct history. The correct history is that I intentionally rejected this patch because the old k8topology hack should really not be used anymore on modern machines (especially not on Quad Cores). SRAT is the far better way to handle this problem because it has a proper abstraction. The problem with k8topology.c is that it needs to know very low level information (like HT node numbers etc.) the kernel should not really need to know and which are difficult to handle generally without motherboard specific knowledge. k8topology.c mostly guesses, which was never a good way to handle this. Also in in the various node has no memory cases it needs quite hackish fallback heuristics which will be always fragile. Then there are some ugly interactions with quad cores. And some other issues I still think the patch a bad idea because adapting this file all the time is a long term maintenance issue. I can say that as the original author :-) It was just a quick hack long ago to get NUMA going early. But now it far outlived its usefulness and adapting it to modern machines is the wrong direction. Best is to phase k8topology out. then with acpi=off, we can not use numa any more. also there are some users are using LinuxBIOS or other firmware that doesn't have or like ACPI support. but they still need numa. for them ACPI doesn't help. YH -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: add PCI IDs to k8topology_64.c
also there are some users are using LinuxBIOS or other firmware that doesn't have or like ACPI support. but they still need numa. for them ACPI doesn't help. We've had this discussion before. The right way even if you don't want to do full ACPI is to do just the minimal static boot tables and a SRAT. These are quite simple tables and should be easy to set up. SRAT is essentially just a two dimensional table with node distances. -Andi -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: add PCI IDs to k8topology_64.c
Andi Kleen wrote: also there are some users are using LinuxBIOS or other firmware that doesn't have or like ACPI support. but they still need numa. for them ACPI doesn't help. We've had this discussion before. The right way even if you don't want to do full ACPI is to do just the minimal static boot tables and a SRAT. These are quite simple tables and should be easy to set up. SRAT is essentially just a two dimensional table with node distances. Indeed. Hacking everything into the kernel just because LinuxBIOS is braindead is NOT a good idea. -hpa -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: add PCI IDs to k8topology_64.c II
SRAT is essentially just a two dimensional table with node distances. Sorry, that was actually SLIT. SRAT is not two dimensional, but also relatively simple. SLIT you don't really need to implement. -Andi -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: add PCI IDs to k8topology_64.c II
On Jan 29, 2008 12:09 AM, Andi Kleen [EMAIL PROTECTED] wrote: SRAT is essentially just a two dimensional table with node distances. Sorry, that was actually SLIT. SRAT is not two dimensional, but also relatively simple. SLIT you don't really need to implement. need to add some CONFIG option to parse SRAT, MADT etc only. but don't pull DSDT related... YH -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86: add PCI IDs to k8topology_64.c II
On Mon, Jan 28, 2008 at 11:39:30PM -0800, Yinghai Lu wrote: On Jan 29, 2008 12:09 AM, Andi Kleen [EMAIL PROTECTED] wrote: SRAT is essentially just a two dimensional table with node distances. Sorry, that was actually SLIT. SRAT is not two dimensional, but also relatively simple. SLIT you don't really need to implement. need to add some CONFIG option to parse SRAT, MADT etc only. but don't pull DSDT related... I don't think it needs a CONFIG. The code should handle this case by itself in any case. I'm not entirely sure it does currently, but if it doesn't it will likely not be very difficult to fix. Or are you worried about code size? ACPI is around ~270k on x86-64, which while certainly not small should not be a problem on x86 NUMA systems. -Andi -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
