- 30 Jan, 2008 40 commits
-
-
Andi Kleen authored
After a lot of discussions with AMD it turns out that TSC on Fam10h CPUs is synchronized when the CONSTANT_TSC cpuid bit is set. Or rather that if there are ever systems where that is not true it would be their BIOS' task to disable the bit. So finally use TSC gettimeofday on Fam10h by default. Or rather it is always used now on CPUs where the AMD specific CONSTANT_TSC bit is set. This gives a nice speed bost for gettimeofday() on these systems which tends to be by far the most common v/syscall. On a Fam10h system here TSC gtod uses about 20% of the CPU time of acpi_pm based gtod(). This was measured on 32bit, on 64bit it is even better because TSC gtod() can use a vsyscall and stay in ring 3, which acpi_pm doesn't. The Intel check simply checks for CONSTANT_TSC too without hardcoding Intel vendor. This is equivalent on 64bit because all 64bit capable Intel CPUs will have CONSTANT_TSC set. On Intel there is no CPU supplied CONSTANT_TSC bit currently, but we synthesize one based on hardcoded knowledge which steppings have p-state invariant TSC. So the new logic is now: On CPUs which have the AMD specific CONSTANT_TSC bit set or on Intel CPUs which are new enough to be known to have p-state invariant TSC always use TSC based gettimeofday() Cc: lenb@kernel.org Signed-off-by:
Andi Kleen <ak@suse.de> Signed-off-by:
Ingo Molnar <mingo@elte.hu> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de>
-
Andi Kleen authored
Need this in the next patch in time_init and that happens early. This includes a minor fix on i386 where early_intel_workarounds() [which is now called early_init_intel] really executes early as the comments say. Signed-off-by:
-
Andi Kleen authored
we need to know whether RDTSC is synchronous or not. Signed-off-by:
-
Ingo Molnar authored
[ andi@firstfloor.org: build fix ] Signed-off-by:
-
Andi Kleen authored
rdtsc is now speculation-safe, so no need for the sync variants of the APIs. [ mingo@elte.hu: removed the nsec_barrier() complication. ] Signed-off-by:
-
Ingo Molnar authored
make native_read_tsc() always non-speculative. Signed-off-by:
-
Ingo Molnar authored
map vsyscalls early enough. This is important if a __vsyscall_fn function is used by other kernel code too. Signed-off-by:
-
Ingo Molnar authored
move native_read_tsc() offline. Signed-off-by:
-
Andi Kleen authored
rdtsc_barrier() is a new barrier primitive that stops RDTSC speculation to avoid races with timer interrupts on other CPUs. It expands either to LFENCE (for Intel CPUs) or MFENCE (for AMD CPUs) which stops RDTSC on all currently known microarchitectures that implement SSE. On CPUs without SSE there is generally no RDTSC speculation. [ mingo@elte.hu: renamed it to rdtsc_barrier() and made it x86-only ] Signed-off-by:
-
WANG Cong authored
Acked-by:
Jeff Dike <jdike@addtoit.com> Signed-off-by:
WANG Cong <xiyou.wangcong@gmail.com> Signed-off-by:
Andrew Morton <akpm@linux-foundation.org> Signed-off-by:
-
Andi Kleen authored
Moving things out of processor.h is always a good thing. Also needed to avoid include loop in later patch. Signed-off-by:
-
Ingo Molnar authored
LFENCE is available on XMM2 or higher Intel CPUs - not XMM or higher... this caused boot failures on XMM1 & !XMM1 capable CPUs. Signed-off-by:
-
Andi Kleen authored
According to Intel RDTSC can be always synchronized with LFENCE on all current CPUs. Implement the necessary CPUID bit for that. It is unclear yet if that is true for all future CPUs too, but if there's another way the kernel can be always updated. Cc: asit.k.mallick@intel.com Signed-off-by:
-
Andi Kleen authored
According to AMD RDTSC can be synchronized through MFENCE. Implement the necessary CPUID bit for that. Cc: andreas.herrmann3@amd.com Signed-off-by:
-
Andi Kleen authored
Signed-off-by:
-
Carlos R. Mafra authored
This patch fixes all errors pointed out by checkpatch.pl. errors lines of code errors/KLOC arch/x86/mm/k8topology_64.c (before) 72 185 389.1 arch/x86/mm/k8topology_64.c (after) 0 185 0 No code changed. text data bss dec hex filename 1506 0 0 1506 5e2 k8topology_64.o.after 1506 0 0 1506 5e2 k8topology_64.o.before md5sum: f9f48331a7eca4fc60d2a03369dc5f53 k8topology_64.o.after f9f48331a7eca4fc60d2a03369dc5f53 k8topology_64.o.before Signed-off-by:Carlos R. Mafra <crmafra@gmail.com> Signed-off-by:
-
Hiroshi Shimamoto authored
More white space and coding style clean up. Signed-off-by:
Hiroshi Shimamoto <h-shimamoto@ct.jp.nec.com> Signed-off-by:
-
Ingo Molnar authored
temporary debugging - remove before this hits v2.6.25. Signed-off-by:
-
Yinghai Lu authored
empty_zero_page is in .bss section, and it is cleared in clear_bss by x86_64_start_kernel(). So don't clear that again in mem_init Signed-off-by:
Yinghai Lu <yinghai.lu@sun.com> Signed-off-by:
-
Hiroshi Shimamoto authored
White space and coding style clean up. Make apic_32/64.c similar. Signed-off-by:
-
Harvey Harrison authored
Use the force_sig_info_fault helper from X86_32 in X86_64. Signed-off-by:
Harvey Harrison <harvey.harrison@gmail.com> Signed-off-by:
-
Harvey Harrison authored
Move X86_32 only get_segment_eip to X86_64 Move X86_64 only is_errata93 to X86_32 Change X86_32 loop in is_prefetch to highlight the differences between them. Fold the logic from __is_prefetch in as well on X86_32. Signed-off-by:
-
Harvey Harrison authored
We get die() from kdebug.h, no need for forward declaration. Signed-off-by:
-
Carlos R. Mafra authored
This patch fixes most errors detected by checkpatch.pl. errors lines of code errors/KLOC arch/x86/oprofile/nmi_int.c (after) 1 461 2.1 arch/x86/oprofile/nmi_int.c (before) 60 477 125.7 No code changed. size: text data bss dec hex filename 2675 264 472 3411 d53 nmi_int.o.after 2675 264 472 3411 d53 nmi_int.o.before md5sum: 847aea0cc68fe1a2b5e7019439f3b4dd nmi_int.o.after 847aea0cc68fe1a2b5e7019439f3b4dd nmi_int.o.before Signed-off-by:Jesper Juhl <jesper.juhl@gmail.com> Signed-off-by:
-
Quentin Barnes authored
When developing the Kprobes arch code for ARM, I ran across some code found in x86 and s390 Kprobes arch code which I didn't consider as good as it could be. Once I figured out what the code was doing, I changed the code for ARM Kprobes to work the way I felt was more appropriate. I've tested the code this way in ARM for about a year and would like to push the same change to the other affected architectures. The code in question is in kprobe_exceptions_notify() which does: ==== /* kprobe_running() needs smp_processor_id() */ preempt_disable(); if (kprobe_running() && kprobe_fault_handler(args->regs, args->trapnr)) ret = NOTIFY_STOP; preempt_enable(); ==== For the moment, ignore the code having the preempt_disable()/ preempt_enable() pair in it. The problem is that kprobe_running() needs to call smp_processor_id() which will assert if preemption is enabled. That sanity check by smp_processor_id() makes perfect sense since calling it with preemption enabled would return an unreliable result. But the function kprobe_exceptions_notify() can be called from a context where preemption could be enabled. If that happens, the assertion in smp_processor_id() happens and we're dead. So what the original author did (speculation on my part!) is put in the preempt_disable()/preempt_enable() pair to simply defeat the check. Once I figured out what was going on, I considered this an inappropriate approach. If kprobe_exceptions_notify() is called from a preemptible context, we can't be in a kprobe processing context at that time anyways since kprobes requires preemption to already be disabled, so just check for preemption enabled, and if so, blow out before ever calling kprobe_running(). I wrote the ARM kprobe code like this: ==== /* To be potentially processing a kprobe fault and to * trust the result from kprobe_running(), we have * be non-preemptible. */ if (!preemptible() && kprobe_running() && kprobe_fault_handler(args->regs, args->trapnr)) ret = NOTIFY_STOP; ==== The above code has been working fine for ARM Kprobes for a year. So I changed the x86 code (2.6.24-rc6) to be the same way and ran the Systemtap tests on that kernel. As on ARM, Systemtap on x86 comes up with the same test results either way, so it's a neutral external functional change (as expected). This issue has been discussed previously on linux-arm-kernel and the Systemtap mailing lists. Pointers to the by base for the two discussions: http://lists.arm.linux.org.uk/lurker/message/20071219.223225.1f5c2a5e.en.html http://sourceware.org/ml/systemtap/2007-q1/msg00251.htmlSigned-off-by:Quentin Barnes <qbarnes@gmail.com> Signed-off-by:
Ananth N Mavinakayahanalli <ananth@in.ibm.com> Acked-by:
-
Cyrill Gorcunov authored
This patch eliminates most of code-style errors discovered by checkpatch.pl on arch/x86/kernel/apm_32.c no code changed: text data bss dec hex filename 12142 1837 84 14063 36ef apm_32.o.before 12142 1837 84 14063 36ef apm_32.o.after md5: 2676b881ad55e387da4a995e8b9ee372 apm_32.o.before.asm 2676b881ad55e387da4a995e8b9ee372 apm_32.o.after.asm Signed-off-by:Cyrill Gorcunov <gorcunov@gmail.com> Signed-off-by:
-
Adrian Bunk authored
PCI is one of the few hardware stuff where defaulting to y makes sense. Signed-off-by:
Adrian Bunk <bunk@kernel.org> Signed-off-by:
-
Sam Ravnborg authored
Teach git to ignore generated files in arch/x86/vdso/* Signed-off-by:
Sam Ravnborg <sam@ravnborg.org> Cc: Roland McGrath <roland@redhat.com> Cc: "H. Peter Anvin" <hpa@zytor.com> Signed-off-by:
-
Cyrill Gorcunov authored
This patch eliminates checkpatch.pl complaints on bootflag.c No code changed: text data bss dec hex filename 321 8 0 329 149 bootflag.o.before 321 8 0 329 149 bootflag.o.after md5: 9c1b474bcf25ddc1724a29c19880043f bootflag.o.before.asm 9c1b474bcf25ddc1724a29c19880043f bootflag.o.after.asm Signed-off-by: -
Ingo Molnar authored
H. Peter Anvin <hpa@zytor.com> wrote: > It probably should actually HLT, to avoid sucking power, and stressing > the thermal system. We're dead at this point, and the early 486's > which had problems with HLT will lock up - we don't care. Signed-off-by:
-
Andrew Morton authored
drivers/pnp/pnpbios/bioscalls.c:64: warning: (near initialization for 'bad_bios_desc.<anonymous>') Signed-off-by:
-
Nick Piggin authored
CONFIG_X86_PPRO_FENCE bloats text: i386 allmodconf: size mm/built-in.o text data bss dec hex text ratio vanilla: 163082 20372 40120 223574 36956 100.00% bugfix : 163509 20372 40120 224001 36b01 0.26% noppro : 162191 20372 40120 222683 365db - 0.55% both : 162267 20372 40120 222759 36627 - 0.50% (+0.05% vs noppro) So with the ppro memory ordering bug out of the way, the PG_uptodate fix only adds 76 bytes of text. allow this config to be specified by distros. [ mingo@elte.hu: x86.git merge ] Signed-off-by: -
Sam Ravnborg authored
Trivial unification of Makefiles for the x86 specific library part. Linking order is slightly modified but should be harmless. Tested doing a defconfig build before and after and saw no build changes. It adds almost as many lines as it deletes - bacause I broke a few lines up fo readability in the Makefile. Signed-off-by:
-
Sam Ravnborg authored
Trivial unification of the two Makefiles. Tested doing a defconfig build for both 32 and 64 bit and no build changes occured. Signed-off-by:
-
Sam Ravnborg authored
Combine the 32 and 64 bit specific Makefiles in one file. While doing so link order was (almost) preserved on 32 bit but on 64 bit link order changed a lot. Patch was checked with defconfig + allyesconfig builds. The same .o files were linked in these configurations. To keep readability of the Makefiles a few Kconfig symbols was added/modified and it was checked that they were not used anywhere else. Signed-off-by:
-
Sam Ravnborg authored
A few files remained after 'make clean' in arch/x86/vdso/. Teach vdso to clean up those files in a bit brutal fashion. The filenames are just hardcoded in the Makefile. Signed-off-by:
-
Sam Ravnborg authored
There were no reason to mess around with CC, AS and LD. Fixing this up avoided duplicated option for ld. A small fixlet were needed in boot/Makefile which assumed that CC were modified. Signed-off-by:
-
Sam Ravnborg authored
On recommendation from Andi Kleen share a few more options between 32 and 64 bit builds. A defconfig build for i386 did not show any difference in size of text and data. The additional shared options are: -Wno-sign-compare -fno-asynchronous-unwind-tables -mno-sse -mno-mmx -mno-sse2 -mno-3dnow Signed-off-by:
-
Sam Ravnborg authored
Unify the 32 and 64 bit specific Makefiles. The unification was simplest to do in one step although the readability of the patch suffers a bit from this. Noteworthy remarks on the unification: - The 64 bit cpu stuff should be moved to Makefile_32.cpu but I did not feel confident doing it due to subtle differences - The use of cflags-y were abandoned since we have seen one bug where we did wrong due to missing assignment to KBUILD_CFLAGS. The cc-option marcro uses KBUILD_CFLAGS. - The "No need to remake" line are deleted. It caused "make -B" to fail - For 64 bit the sub architecture stuff is not used. - The way head64.o is specified could be nicer - but it awaits the introduction of head32.o (which seems like a win to introduce for readability) - Patch is checkpatch clean Patch is tested by doing a defconfig build for i386 and x86_64 and in both cases monitoring that only relevant files were recompiled when applying the patch. [ mingo@elte.hu: build fix ] Signed-off-by:
-
Harvey Harrison authored
Make the control flow of kprobe_handler more obvious. Collapse the separate if blocks/gotos with if/else blocks this unifies the duplication of the check for a breakpoint instruction race with another cpu. Create two jump targets: preempt_out: re-enables preemption before returning ret out: only returns ret Signed-off-by:
-
