Revision tags: v2.6.21-rc2, v2.6.21-rc1 |
|
#
a8d91b84 |
| 12-Feb-2007 |
Alon Bar-Lev <alon.barlev@gmail.com> |
[PATCH] Dynamic kernel command-line: ia64
1. Rename saved_command_line into boot_command_line. 2. Set command_line as __initdata.
[akpm@osdl.org: move some declarations to the right place] Signed-o
[PATCH] Dynamic kernel command-line: ia64
1. Rename saved_command_line into boot_command_line. 2. Set command_line as __initdata.
[akpm@osdl.org: move some declarations to the right place] Signed-off-by: Alon Bar-Lev <alon.barlev@gmail.com> Cc: "Luck, Tony" <tony.luck@intel.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
show more ...
|
Revision tags: v2.6.20, v2.6.20-rc7, v2.6.20-rc6, v2.6.20-rc5, v2.6.20-rc4, v2.6.20-rc3, v2.6.20-rc2, v2.6.20-rc1, v2.6.19, v2.6.19-rc6, v2.6.19-rc5, v2.6.19-rc4, v2.6.19-rc3 |
|
#
a0776ec8 |
| 13-Oct-2006 |
Chen, Kenneth W <kenneth.w.chen@intel.com> |
[IA64] remove per-cpu ia64_phys_stacked_size_p8
It's not efficient to use a per-cpu variable just to store how many physical stack register a cpu has. Ever since the incarnation of ia64 up till upc
[IA64] remove per-cpu ia64_phys_stacked_size_p8
It's not efficient to use a per-cpu variable just to store how many physical stack register a cpu has. Ever since the incarnation of ia64 up till upcoming Montecito processor, that variable has "glued" to 96. Having a variable in memory means that the kernel is burning an extra cacheline access on every syscall and kernel exit path. Such "static" value is better served with the instruction patching utility exists today. Convert ia64_phys_stacked_size_p8 into dynamic insn patching.
This also has a pleasant side effect of eliminating access to per-cpu area while psr.ic=0 in the kernel exit path. (fixable for per-cpu DTC work, but why bother?)
There are some concerns with the default value that the instruc- tion encoded in the kernel image. It shouldn't be concerned. The reasons are:
(1) cpu_init() is called at CPU initialization. In there, we find out physical stack register size from PAL and patch two instructions in kernel exit code. The code in question can not be executed before the patching is done.
(2) current implementation stores zero in ia64_phys_stacked_size_p8, and that's what the current kernel exit path loads the value with. With the new code, it is equivalent that we store reg size 96 in ia64_phys_stacked_size_p8, thus creating a better safety net. Given (1) above can never fail, having (2) is just a bonus.
All in all, this patch allow one less memory reference in the kernel exit path, thus reducing syscall and interrupt return latency; and avoid polluting potential useful data in the CPU cache.
Signed-off-by: Ken Chen <kenneth.w.chen@intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
show more ...
|
#
ae0af3e3 |
| 05-Feb-2007 |
Aron Griffis <aron@hp.com> |
[IA64] use snprintf() on features field of /proc/cpuinfo
Some patches have turned up on xen-devel recently to convert strcpy() to safer alternatives and so forth. While reviewing those patches I no
[IA64] use snprintf() on features field of /proc/cpuinfo
Some patches have turned up on xen-devel recently to convert strcpy() to safer alternatives and so forth. While reviewing those patches I noticed that the features string building could be cleaned up.
This patch uses snprintf() instead of strcpy() and direct character pointer manipulation. It makes the features string building safe and gets rid of the special case for features output in show_cpuinfo()
Additionally I removed the (int) cast of ARRAY_SIZE, which seems to serve no purpose.
Signed-off-by: Aron Griffis <aron@hp.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
show more ...
|
#
75f6a1de |
| 12-Dec-2006 |
Tony Luck <tony.luck@intel.com> |
[IA64] Take defensive stance on ia64_pal_get_brand_info()
Stephane thought he saw a problem here (but was just confused by the return value from ia64_pal_get_brand_info()). But we should be more de
[IA64] Take defensive stance on ia64_pal_get_brand_info()
Stephane thought he saw a problem here (but was just confused by the return value from ia64_pal_get_brand_info()). But we should be more defensive here in case an prototype PAL for a future processor doesn't implement this PAL call.
Signed-off-by: Tony Luck <tony.luck@intel.com>
show more ...
|
#
ad1c3ba7 |
| 12-Dec-2006 |
Horms <horms@verge.net.au> |
[IA64] Kexec/Kdump: honour non-zero crashkernel offset.
There seems to be a value in both allowing the kernel to determine the base offset of the crashkernel automatically and allowing users's to se
[IA64] Kexec/Kdump: honour non-zero crashkernel offset.
There seems to be a value in both allowing the kernel to determine the base offset of the crashkernel automatically and allowing users's to sepcify it.
The old behaviour on ia64, which is still the current behaviour on most architectures is for the user to always specify the address. Recently ia64 was changed so that it is always automatically determined.
With this patch the kernel automatically determines the offset if the supplied value is 0, otherwise it uses the value provided.
This should probably be backed by a documentation change.
Signed-Off-By: Simon Horman <horms@verge.net.au> Signed-off-by: Tony Luck <tony.luck@intel.com>
show more ...
|
#
45a98fc6 |
| 12-Dec-2006 |
Horms <horms@verge.net.au> |
[IA64] CONFIG_KEXEC/CONFIG_CRASH_DUMP permutations
Actually, on reflection I think that there is a good case for keeping the options separate. I am thinking particularly of people who want a very sm
[IA64] CONFIG_KEXEC/CONFIG_CRASH_DUMP permutations
Actually, on reflection I think that there is a good case for keeping the options separate. I am thinking particularly of people who want a very small crashdump kernel and thus don't want to compile in kexec.
The patch below should fix things up so that all valid combinations of KEXEC, CRASH_DUMP and VMCORE compile cleanly - VMCORE depends on CRASH_DUMP which is why I said valid combinations. In a nutshell it just untangles unrelated code and switches around a few defines.
Please note that it creats a new file, arch/ia64/kernel/crash_dump.c This is in keeping with the i386 implementation.
Signed-off-by: Simon Horman <horms@verge.net.au> Signed-off-by: Tony Luck <tony.luck@intel.com>
show more ...
|
#
a7956113 |
| 07-Dec-2006 |
Zou Nan hai <nanhai.zou@intel.com> |
[IA64] IA64 Kexec/kdump
Changes and updates.
1. Remove fake rendz path and related code according to discuss with Khalid Aziz. 2. fc.i offset fix in relocate_kernel.S. 3. iospic shutdown code eoi a
[IA64] IA64 Kexec/kdump
Changes and updates.
1. Remove fake rendz path and related code according to discuss with Khalid Aziz. 2. fc.i offset fix in relocate_kernel.S. 3. iospic shutdown code eoi and mask race fix from Fujitsu. 4. Warm boot hook in machine_kexec to SN SAL code from Jack Steiner. 5. Send slave to SAL slave loop patch from Jay Lan. 6. Kdump on non-recoverable MCA event patch from Jay Lan 7. Use CTL_UNNUMBERED in kdump_on_init sysctl.
Signed-off-by: Zou Nan hai <nanhai.zou@intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
show more ...
|
#
fa1d19e5 |
| 25-Oct-2006 |
Troy Heber <troy.heber@hp.com> |
[IA64] move SAL_CACHE_FLUSH check later in boot
The check to see if the firmware drops interrupts during a SAL_CACHE_FLUSH is done to early in the boot. SAL_CACHE_FLUSH expects to be able to make PA
[IA64] move SAL_CACHE_FLUSH check later in boot
The check to see if the firmware drops interrupts during a SAL_CACHE_FLUSH is done to early in the boot. SAL_CACHE_FLUSH expects to be able to make PAL calls in virtual mode, on some cell based machines a fault occurs causing a MCA. This patch moves the check after mmu_context_init so the TLB and VHPT are properly setup.
Signed-off-by Troy Heber <troy.heber@hp.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
show more ...
|
Revision tags: v2.6.19-rc2, v2.6.19-rc1, v2.6.18, v2.6.18-rc7, v2.6.18-rc6 |
|
#
bcf5111a |
| 30-Aug-2006 |
Russell King <rmk@dyn-67.arm.linux.org.uk> |
[SERIAL] Remove wrong asm/serial.h inclusions
asm/serial.h is supposed to contain the definitions for the architecture specific 8250 ports for the 8250 driver. It may also define BASE_BAUD, but thi
[SERIAL] Remove wrong asm/serial.h inclusions
asm/serial.h is supposed to contain the definitions for the architecture specific 8250 ports for the 8250 driver. It may also define BASE_BAUD, but this is the base baud for the architecture specific ports _only_.
Therefore, nothing other than the 8250 driver should be including this header file. In order to move towards this goal, here is a patch which removes some of the more obvious incorrect includes of the file.
Acked-by: Paul Fulghum <paulkf@microgate.com> Acked-by: Tony Luck <tony.luck@intel.com> Acked-by: Ralf Baechle <ralf@linux-mips.org> Acked-by: David Howells <dhowells@redhat.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
show more ...
|
Revision tags: v2.6.18-rc5, v2.6.18-rc4, v2.6.18-rc3, v2.6.18-rc2 |
|
#
894673ee |
| 10-Jul-2006 |
Jon Smirl <jonsmir@gmail.com> |
[PATCH] tty: Remove include of screen_info.h from tty.h
screen_info.h doesn't have anything to do with the tty layer and shouldn't be included by tty.h. This patches removes the include and modifie
[PATCH] tty: Remove include of screen_info.h from tty.h
screen_info.h doesn't have anything to do with the tty layer and shouldn't be included by tty.h. This patches removes the include and modifies all users to directly include screen_info.h. struct screen_info is mainly used to communicate with the console drivers in drivers/video/console. Note that this patch touches every arch and I have no way of testing it. If there is a mistake the worst thing that will happen is a compile error.
[akpm@osdl.org: fix arm build] [akpm@osdl.org: fix alpha build] Signed-off-by: Jon Smirl <jonsmir@gmail.com> Signed-off-by: Antonino Daplas <adaplas@pol.net> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
show more ...
|
Revision tags: v2.6.18-rc1 |
|
#
6ab3d562 |
| 30-Jun-2006 |
Jörn Engel <joern@wohnheim.fh-wedel.de> |
Remove obsolete #include <linux/config.h>
Signed-off-by: Jörn Engel <joern@wohnheim.fh-wedel.de> Signed-off-by: Adrian Bunk <bunk@stusta.de>
|
Revision tags: v2.6.17 |
|
#
5eb1d63f |
| 06-Jun-2006 |
Alex Williamson <alex.williamson@hp.com> |
[IA64] sanity check reserved region usage
One more trivial, stand-alone patch from the Xen/ia64 review. Sanity check usage of the reserved region numbers.
Signed-off-by: Alex Williamson <alex.will
[IA64] sanity check reserved region usage
One more trivial, stand-alone patch from the Xen/ia64 review. Sanity check usage of the reserved region numbers.
Signed-off-by: Alex Williamson <alex.williamson@hp.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
show more ...
|
Revision tags: v2.6.17-rc6 |
|
#
76d08bb3 |
| 05-Jun-2006 |
Tony Luck <tony.luck@intel.com> |
[IA64] Add "model name" to /proc/cpuinfo
Linux ia64 port tried to decode the processor family number to something human-readable, but Intel brandnames don't change synchronously with updates to the
[IA64] Add "model name" to /proc/cpuinfo
Linux ia64 port tried to decode the processor family number to something human-readable, but Intel brandnames don't change synchronously with updates to the family number. Adopt a more i386-like approach and just print the family number in decimal. Add a new field "model name" that uses PAL_BRAND_INFO to find the official name for the cpu, or on older systems, falls back to using the well-known codenames (Merced, McKinley, Madison).
Signed-off-by: Tony Luck <tony.luck@intel.com>
show more ...
|
Revision tags: v2.6.17-rc5, v2.6.17-rc4, v2.6.17-rc3, v2.6.17-rc2, v2.6.17-rc1 |
|
#
b2c99e3c |
| 26-Mar-2006 |
Bjorn Helgaas <bjorn.helgaas@hp.com> |
[PATCH] EFI: keep physical table addresses in efi structure
Almost all users of the table addresses from the EFI system table want physical addresses. So rather than doing the pa->va->pa conversion
[PATCH] EFI: keep physical table addresses in efi structure
Almost all users of the table addresses from the EFI system table want physical addresses. So rather than doing the pa->va->pa conversion, just keep physical addresses in struct efi.
This fixes a DMI bug: the efi structure contained the physical SMBIOS address on x86 but the virtual address on ia64, so dmi_scan_machine() used ioremap() on a virtual address on ia64.
This is essentially the same as an earlier patch by Matt Tolentino: http://marc.theaimsgroup.com/?l=linux-kernel&m=112130292316281&w=2 except that this changes all table addresses, not just ACPI addresses.
Matt's original patch was backed out because it caused MCAs on HP sx1000 systems. That problem is resolved by the ioremap() attribute checking added for ia64.
Signed-off-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Cc: Matt Domsch <Matt_Domsch@dell.com> Cc: "Tolentino, Matthew E" <matthew.e.tolentino@intel.com> Cc: "Brown, Len" <len.brown@intel.com> Cc: Andi Kleen <ak@muc.de> Acked-by: "Luck, Tony" <tony.luck@intel.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
show more ...
|
#
3ed3bce8 |
| 26-Mar-2006 |
Matt Domsch <Matt_Domsch@dell.com> |
[PATCH] ia64: use i386 dmi_scan.c
Enable DMI table parsing on ia64.
Andi Kleen has a patch in his x86_64 tree which enables the use of i386 dmi_scan.c on x86_64. dmi_scan.c functions are being use
[PATCH] ia64: use i386 dmi_scan.c
Enable DMI table parsing on ia64.
Andi Kleen has a patch in his x86_64 tree which enables the use of i386 dmi_scan.c on x86_64. dmi_scan.c functions are being used by the drivers/char/ipmi/ipmi_si_intf.c driver for autodetecting the ports or memory spaces where the IPMI controllers may be found.
This patch adds equivalent changes for ia64 as to what is in the x86_64 tree. In addition, I reworked the DMI detection, such that on EFI-capable systems, it uses the efi.smbios pointer to find the table, rather than brute-force searching from 0xF0000. On non-EFI systems, it continues the brute-force search.
My test system, an Intel S870BN4 'Tiger4', aka Dell PowerEdge 7250, with latest BIOS, does not list the IPMI controller in the ACPI namespace, nor does it have an ACPI SPMI table. Also note, currently shipping Dell x8xx EM64T servers don't have these either, so DMI is the only method for obtaining the address of the IPMI controller.
Signed-off-by: Matt Domsch <Matt_Domsch@dell.com> Acked-by: "Luck, Tony" <tony.luck@intel.com> Cc: Andi Kleen <ak@muc.de> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
show more ...
|
#
cdb04527 |
| 24-Mar-2006 |
Adrian Bunk <bunk@stusta.de> |
[PATCH] kill include/linux/platform.h, default_idle() cleanup
include/linux/platform.h contained nothing that was actually used except the default_idle() prototype, and is therefore removed by this
[PATCH] kill include/linux/platform.h, default_idle() cleanup
include/linux/platform.h contained nothing that was actually used except the default_idle() prototype, and is therefore removed by this patch.
This patch does the following with the platform specific default_idle() functions on different architectures: - remove the unused function: - parisc - sparc64 - make the needlessly global function static: - arm - h8300 - m68k - m68knommu - s390 - v850 - x86_64 - add a prototype in asm/system.h: - cris - i386 - ia64
Signed-off-by: Adrian Bunk <bunk@stusta.de> Acked-by: Patrick Mochel <mochel@digitalimplant.org> Acked-by: Kyle McMartin <kyle@parisc-linux.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
show more ...
|
#
a5b00bb4 |
| 23-Mar-2006 |
Horms <horms@verge.net.au> |
IA64: Use early_parm to handle mvec_name and nomca
I'm not sure of the worthiness of this idea, so please consider it an RFC. Its key merits are:
* Reuse existing infrastructure * Greatly tightens
IA64: Use early_parm to handle mvec_name and nomca
I'm not sure of the worthiness of this idea, so please consider it an RFC. Its key merits are:
* Reuse existing infrastructure * Greatly tightens up the parsing of nomca * Greatly simplifies the parsing of machvec
Addition cleanup (moving setup_mvec() to machvec.c) by Ken Chen.
Signed-Off-By: Horms <horms@verge.net.au> Signed-Off-By: Tony Luck <tony.luck@intel.com>
show more ...
|
#
dae28066 |
| 22-Mar-2006 |
Chen, Kenneth W <kenneth.w.chen@intel.com> |
[IA64] add init declaration to memory initialization functions
Add init declaration to variables/functions used for memory initialization. I don't think they would clash with memory hotplug. If th
[IA64] add init declaration to memory initialization functions
Add init declaration to variables/functions used for memory initialization. I don't think they would clash with memory hotplug. If they do, please yell.
Signed-off-by: Ken Chen <kenneth.w.chen@intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
show more ...
|
Revision tags: v2.6.16 |
|
#
244fd545 |
| 12-Mar-2006 |
Chen, Kenneth W <kenneth.w.chen@intel.com> |
[IA64] add init declaration to cpu initialization functions
Add init declaration to cpu initialization functions.
Signed-off-by: Ken Chen <kenneth.w.chen@intel.com> Signed-off-by: Tony Luck <tony.l
[IA64] add init declaration to cpu initialization functions
Add init declaration to cpu initialization functions.
Signed-off-by: Ken Chen <kenneth.w.chen@intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
show more ...
|
Revision tags: v2.6.16-rc6, v2.6.16-rc5, v2.6.16-rc4 |
|
#
a6b14fa6 |
| 14-Feb-2006 |
Ashok Raj <ashok.raj@intel.com> |
[IA64] Count disabled cpus as potential hot-pluggable CPUs
Have a facility to account for potentially hot-pluggable CPUs. ACPI doesnt give a determinstic method to find hot-pluggable CPUs. Hence we
[IA64] Count disabled cpus as potential hot-pluggable CPUs
Have a facility to account for potentially hot-pluggable CPUs. ACPI doesnt give a determinstic method to find hot-pluggable CPUs. Hence we use 2 methods to assist.
- BIOS can mark potentially hot-pluggable CPUs as disabled in the MADT tables. - User can specify the number of hot-pluggable CPUs via parameter additional_cpus=X
The option is enabled only if ACPI_CONFIG_HOTPLUG_CPU=y which enables the physical hotplug option. Without which user can still use logical onlining and offlining of CPUs by enabling CONFIG_HOTPLUG_CPU=y
Adds more bits to cpu_possible_map for potentially hot-pluggable cpus.
Signed-off-by: Ashok Raj <ashok.raj@intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com>
show more ...
|
Revision tags: v2.6.16-rc3 |
|
#
d6e56a2a |
| 07-Feb-2006 |
Tony Luck <tony.luck@intel.com> |
[IA64] Fix CONFIG_PRINTK_TIME
There were two problems with enabling the PRINTK_TIME config option: 1) The first calls to printk() occur before per-cpu data virtual address is pinned into the TLB, so
[IA64] Fix CONFIG_PRINTK_TIME
There were two problems with enabling the PRINTK_TIME config option: 1) The first calls to printk() occur before per-cpu data virtual address is pinned into the TLB, so sched_clock() can fault. 2) sched_clock() is based on ar.itc, which may not be synchronized across cpus.
Ken Chen started this patch, Tony Luck tinkered with it, and Jes Sorensen perfected it.
Signed-off-by: Tony Luck <tony.luck@intel.com>
show more ...
|
Revision tags: v2.6.16-rc2, v2.6.16-rc1 |
|
#
6450578f |
| 12-Jan-2006 |
Al Viro <viro@ftp.linux.org.uk> |
[PATCH] ia64: task_pt_regs()
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
|
#
198e2f18 |
| 12-Jan-2006 |
akpm@osdl.org <akpm@osdl.org> |
[PATCH] scheduler cache-hot-autodetect
)
From: Ingo Molnar <mingo@elte.hu>
This is the latest version of the scheduler cache-hot-auto-tune patch.
The first problem was that detection time scaled
[PATCH] scheduler cache-hot-autodetect
)
From: Ingo Molnar <mingo@elte.hu>
This is the latest version of the scheduler cache-hot-auto-tune patch.
The first problem was that detection time scaled with O(N^2), which is unacceptable on larger SMP and NUMA systems. To solve this:
- I've added a 'domain distance' function, which is used to cache measurement results. Each distance is only measured once. This means that e.g. on NUMA distances of 0, 1 and 2 might be measured, on HT distances 0 and 1, and on SMP distance 0 is measured. The code walks the domain tree to determine the distance, so it automatically follows whatever hierarchy an architecture sets up. This cuts down on the boot time significantly and removes the O(N^2) limit. The only assumption is that migration costs can be expressed as a function of domain distance - this covers the overwhelming majority of existing systems, and is a good guess even for more assymetric systems.
[ People hacking systems that have assymetries that break this assumption (e.g. different CPU speeds) should experiment a bit with the cpu_distance() function. Adding a ->migration_distance factor to the domain structure would be one possible solution - but lets first see the problem systems, if they exist at all. Lets not overdesign. ]
Another problem was that only a single cache-size was used for measuring the cost of migration, and most architectures didnt set that variable up. Furthermore, a single cache-size does not fit NUMA hierarchies with L3 caches and does not fit HT setups, where different CPUs will often have different 'effective cache sizes'. To solve this problem:
- Instead of relying on a single cache-size provided by the platform and sticking to it, the code now auto-detects the 'effective migration cost' between two measured CPUs, via iterating through a wide range of cachesizes. The code searches for the maximum migration cost, which occurs when the working set of the test-workload falls just below the 'effective cache size'. I.e. real-life optimized search is done for the maximum migration cost, between two real CPUs.
This, amongst other things, has the positive effect hat if e.g. two CPUs share a L2/L3 cache, a different (and accurate) migration cost will be found than between two CPUs on the same system that dont share any caches.
(The reliable measurement of migration costs is tricky - see the source for details.)
Furthermore i've added various boot-time options to override/tune migration behavior.
Firstly, there's a blanket override for autodetection:
migration_cost=1000,2000,3000
will override the depth 0/1/2 values with 1msec/2msec/3msec values.
Secondly, there's a global factor that can be used to increase (or decrease) the autodetected values:
migration_factor=120
will increase the autodetected values by 20%. This option is useful to tune things in a workload-dependent way - e.g. if a workload is cache-insensitive then CPU utilization can be maximized by specifying migration_factor=0.
I've tested the autodetection code quite extensively on x86, on 3 P3/Xeon/2MB, and the autodetected values look pretty good:
Dual Celeron (128K L2 cache):
--------------------- migration cost matrix (max_cache_size: 131072, cpu: 467 MHz): --------------------- [00] [01] [00]: - 1.7(1) [01]: 1.7(1) - --------------------- cacheflush times [2]: 0.0 (0) 1.7 (1784008) ---------------------
Here the slow memory subsystem dominates system performance, and even though caches are small, the migration cost is 1.7 msecs.
Dual HT P4 (512K L2 cache):
--------------------- migration cost matrix (max_cache_size: 524288, cpu: 2379 MHz): --------------------- [00] [01] [02] [03] [00]: - 0.4(1) 0.0(0) 0.4(1) [01]: 0.4(1) - 0.4(1) 0.0(0) [02]: 0.0(0) 0.4(1) - 0.4(1) [03]: 0.4(1) 0.0(0) 0.4(1) - --------------------- cacheflush times [2]: 0.0 (33900) 0.4 (448514) ---------------------
Here it can be seen that there is no migration cost between two HT siblings (CPU#0/2 and CPU#1/3 are separate physical CPUs). A fast memory system makes inter-physical-CPU migration pretty cheap: 0.4 msecs.
8-way P3/Xeon [2MB L2 cache]:
--------------------- migration cost matrix (max_cache_size: 2097152, cpu: 700 MHz): --------------------- [00] [01] [02] [03] [04] [05] [06] [07] [00]: - 19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1) [01]: 19.2(1) - 19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1) [02]: 19.2(1) 19.2(1) - 19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1) [03]: 19.2(1) 19.2(1) 19.2(1) - 19.2(1) 19.2(1) 19.2(1) 19.2(1) [04]: 19.2(1) 19.2(1) 19.2(1) 19.2(1) - 19.2(1) 19.2(1) 19.2(1) [05]: 19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1) - 19.2(1) 19.2(1) [06]: 19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1) - 19.2(1) [07]: 19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1) 19.2(1) - --------------------- cacheflush times [2]: 0.0 (0) 19.2 (19281756) ---------------------
This one has huge caches and a relatively slow memory subsystem - so the migration cost is 19 msecs.
Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Ashok Raj <ashok.raj@intel.com> Signed-off-by: Ken Chen <kenneth.w.chen@intel.com> Cc: <wilder@us.ibm.com> Signed-off-by: John Hawkes <hawkes@sgi.com> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
show more ...
|
#
4dc7a0bb |
| 12-Jan-2006 |
Ingo Molnar <mingo@elte.hu> |
[PATCH] sched: add cacheflush() asm
Add per-arch sched_cacheflush() which is a write-back cacheflush used by the migration-cost calibration code at bootup time.
Signed-off-by: Ingo Molnar <mingo@el
[PATCH] sched: add cacheflush() asm
Add per-arch sched_cacheflush() which is a write-back cacheflush used by the migration-cost calibration code at bootup time.
Signed-off-by: Ingo Molnar <mingo@elte.hu> Cc: Nick Piggin <nickpiggin@yahoo.com.au> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
show more ...
|
#
38c0b2c2 |
| 05-Jan-2006 |
Tony Luck <tony.luck@intel.com> |
[IA64] Fix compile warnings in setup.c
arch/ia64/kernel/setup.c: In function `show_cpuinfo': arch/ia64/kernel/setup.c:576: warning: long unsigned int format, different type arg (arg 12) arch/ia64/ke
[IA64] Fix compile warnings in setup.c
arch/ia64/kernel/setup.c: In function `show_cpuinfo': arch/ia64/kernel/setup.c:576: warning: long unsigned int format, different type arg (arg 12) arch/ia64/kernel/setup.c:576: warning: long unsigned int format, different type arg (arg 13)
Introduced by 95235ca2c20ac0b31a8eb39e2d599bcc3e9c9a10
Signed-off-by: Tony Luck <tony.luck@intel.com>
show more ...
|