Date: Mon, 2 Apr 2007 10:10:55 -0700 From: Marcel Moolenaar <xcllnt@mac.com> To: John Baldwin <jhb@freebsd.org> Cc: Marcel Moolenaar <marcel@freebsd.org>, Perforce Change Reviews <perforce@freebsd.org> Subject: Re: PERFORCE change 117140 for review Message-ID: <645BFA2D-3FC3-4AAB-ADCC-8D18431688E9@mac.com> In-Reply-To: <200704021155.21453.jhb@freebsd.org> References: <200704012152.l31LqHuB022635@repoman.freebsd.org> <200704020915.03985.jhb@freebsd.org> <CDC52365-B23A-4852-8AAD-0808C38F8380@mac.com> <200704021155.21453.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Apr 2, 2007, at 8:55 AM, John Baldwin wrote: >> For example, to analyze machine checks on on pluto1, I disabled CPU0 >> and CPU1 in succession to see if one of the CPUs was the cause of the >> MC. As such, CPU1 had to be the BSP when CPU0 was disabled. Luckily >> pluto1 is only a dual-CPU machine, so that disabling a CPU also stops >> SMP operation :-) > > FreeBSD CPU ID's != firmware CPU IDs. It is important, and not only for identification, that the logical CPU ID used by FreeBSD is the same as used by the firmware (if at all possible). A different ID only causes confusion, especially when the firmware draws its IDs from the same domain. What is called CPU4 within FreeBSD may not be called CPU4 in the firmware, even though CPU4 may exist. > CPU ID's != local APIC ID's on x86 for example, nor > are they identical to the CPU indices in the hwprb on Alpha. They are also not the same on ia64. In fact, on ia64 the APIC ID consists of 2 elements. The ACPI ID is exactly the kind of ID we want... > FreeBSD CPU > ID's tend to not be sparse for example, because they are completely > separate > from firmware IDs. This statement is flawed. Sparseness is unavoidable when CPUs can be hot-plugged. While we should have a CPU ID that maps trivially to a bit field for masking purposes, there's no reason to allow sparse IDs to certain extend. Both ACPI and Open Firmware have CPU IDs that map trivially to a mask and they tend to be dense. I see no reason to not use the firmware IDs as FreeBSD's notion of CPU ID. In fact, I see reasons not to create our own IDs. In such reason is the added overhead of mapping from one to the other during runtime. I think that testing for CPU0 when we really want to know if we're running on the BSP is also flawed. On ia64 there's typically 1 BSP that is used to boot the machine, but each cell in a NUMA system has a monarch CPU that serves the purpose of the BSP for that cell. This means that some tests that check for the BSP may need to be changed to check for the monarch instead. Since there can obviously be only 1 CPU0, there will (ipso facto) be BSP-like processors with an ID != 0. It's therefore better not to assume "special powers" for CPU0 and instead check the PCPU for flags that corresponds 1-on-1 with such powers. -- Marcel Moolenaar xcllnt@mac.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?645BFA2D-3FC3-4AAB-ADCC-8D18431688E9>