- 07 Sep, 2005 11 commits
-
-
Jakub Jelinek authored
ATM pthread_cond_signal is unnecessarily slow, because it wakes one waiter (which at least on UP usually means an immediate context switch to one of the waiter threads). This waiter wakes up and after a few instructions it attempts to acquire the cv internal lock, but that lock is still held by the thread calling pthread_cond_signal. So it goes to sleep and eventually the signalling thread is scheduled in, unlocks the internal lock and wakes the waiter again. Now, before 2003-09-21 NPTL was using FUTEX_REQUEUE in pthread_cond_signal to avoid this performance issue, but it was removed when locks were redesigned to the 3 state scheme (unlocked, locked uncontended, locked contended). Following scenario shows why simply using FUTEX_REQUEUE in pthread_cond_signal together with using lll_mutex_unlock_force in place of lll_mutex_unlock is not enough and probably why it has been disabled at that time: The number is value in cv->__data.__lock. thr1 thr2 thr3 0 pthread_cond_wait 1 lll_mutex_lock (cv->__data.__lock) 0 lll_mutex_unlock (cv->__data.__lock) 0 lll_futex_wait (&cv->__data.__futex, futexval) 0 pthread_cond_signal 1 lll_mutex_lock (cv->__data.__lock) 1 pthread_cond_signal 2 lll_mutex_lock (cv->__data.__lock) 2 lll_futex_wait (&cv->__data.__lock, 2) 2 lll_futex_requeue (&cv->__data.__futex, 0, 1, &cv->__data.__lock) # FUTEX_REQUEUE, not FUTEX_CMP_REQUEUE 2 lll_mutex_unlock_force (cv->__data.__lock) 0 cv->__data.__lock = 0 0 lll_futex_wake (&cv->__data.__lock, 1) 1 lll_mutex_lock (cv->__data.__lock) 0 lll_mutex_unlock (cv->__data.__lock) # Here, lll_mutex_unlock doesn't know there are threads waiting # on the internal cv's lock Now, I believe it is possible to use FUTEX_REQUEUE in pthread_cond_signal, but it will cost us not one, but 2 extra syscalls and, what's worse, one of these extra syscalls will be done for every single waiting loop in pthread_cond_*wait. We would need to use lll_mutex_unlock_force in pthread_cond_signal after requeue and lll_mutex_cond_lock in pthread_cond_*wait after lll_futex_wait. Another alternative is to do the unlocking pthread_cond_signal needs to do (the lock can't be unlocked before lll_futex_wake, as that is racy) in the kernel. I have implemented both variants, futex-requeue-glibc.patch is the first one and futex-wake_op{,-glibc}.patch is the unlocking inside of the kernel. The kernel interface allows userland to specify how exactly an unlocking operation should look like (some atomic arithmetic operation with optional constant argument and comparison of the previous futex value with another constant). It has been implemented just for ppc*, x86_64 and i?86, for other architectures I'm including just a stub header which can be used as a starting point by maintainers to write support for their arches and ATM will just return -ENOSYS for FUTEX_WAKE_OP. The requeue patch has been (lightly) tested just on x86_64, the wake_op patch on ppc64 kernel running 32-bit and 64-bit NPTL and x86_64 kernel running 32-bit and 64-bit NPTL. With the following benchmark on UP x86-64 I get: for i in nptl-orig nptl-requeue nptl-wake_op; do echo time elf/ld.so --library-path .:$i /tmp/bench; \ for j in 1 2; do echo ( time elf/ld.so --library-path .:$i /tmp/bench ) 2>&1; done; done time elf/ld.so --library-path .:nptl-orig /tmp/bench real 0m0.655s user 0m0.253s sys 0m0.403s real 0m0.657s user 0m0.269s sys 0m0.388s time elf/ld.so --library-path .:nptl-requeue /tmp/bench real 0m0.496s user 0m0.225s sys 0m0.271s real 0m0.531s user 0m0.242s sys 0m0.288s time elf/ld.so --library-path .:nptl-wake_op /tmp/bench real 0m0.380s user 0m0.176s sys 0m0.204s real 0m0.382s user 0m0.175s sys 0m0.207s The benchmark is at: http://sourceware.org/ml/libc-alpha/2005-03/txt00001.txt Older futex-requeue-glibc.patch version is at: http://sourceware.org/ml/libc-alpha/2005-03/txt00002.txt Older futex-wake_op-glibc.patch version is at: http://sourceware.org/ml/libc-alpha/2005-03/txt00003.txt Will post a new version (just x86-64 fixes so that the patch applies against pthread_cond_signal.S) to libc-hacker ml soon. Attached is the kernel FUTEX_WAKE_OP patch as well as a simple-minded testcase that will not test the atomicity of the operation, but at least check if the threads that should have been woken up are woken up and whether the arithmetic operation in the kernel gave the expected results. Acked-by:Ingo Molnar <mingo@redhat.com> Cc: Ulrich Drepper <drepper@redhat.com> Cc: Jamie Lokier <jamie@shareable.org> Cc: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by:
Yoichi Yuasa <yuasa@hh.iij4u.or.jp> Signed-off-by:
Andrew Morton <akpm@osdl.org> Signed-off-by:
Linus Torvalds <torvalds@osdl.org>
-
Rafael J. Wysocki authored
This patch adds some missing pci-related calls to the suspend and resume routines of the 3c59x driver. It also makes the driver free/request IRQ on suspend/resume, in accordance with the proposal at: http://lists.osdl.org/pipermail/linux-pm/2005-May/000955.htmlSigned-off-by:
-
Pavel Machek authored
This updates documentation a bit (mostly removing obsolete stuff), and marks swsusp as no longer experimental in config. Signed-off-by:
Pavel Machek <pavel@suse.cz> Signed-off-by:
-
Eric W. Biederman authored
This allows a valid iommu placed immediately after memory to work, to be recognized as after the last byte of memory and not overlapping it. Signed-off-by:
Eric W. Biederman <ebiederm@xmission.com> Acked-by:
Andi Kleen <ak@suse.de> Signed-off-by:
-
Ashok Raj authored
Need to create sysfs only for cpus that are present. Without which we see NR_CPUS entries created when we have CONFIG_HOTPLUG and CONFIG_HOTPLUG_CPU enabled. Signed-off-by:
Ashok Raj <ashok.raj@intel.com> Acked-by:
Andi Kleen <ak@muc.de> Signed-off-by:
-
Ashok Raj authored
Need to ensure we dont get prempted when we clear ourself from mask when using clustered mode genapic code. Signed-off-by:
-
Eric Dumazet authored
This is a multi-part message in MIME format. If the cpu lacks 3DNOW feature, we can use a normal prefetcht0 instruction instead of NOP5. "prefetchw (%rxx)" and "prefetcht0 (%rxx)" have the same length, ranging from 3 to 5 bytes depending on the register. So this patch even helps AMD64, shortening the length of the code. Signed-off-by:
Eric Dumazet <dada1@cosmosbay.com> Acked-by:
-
Zwane Mwaikambo authored
Up to date I've been using the GS value to determine the processor number in dumps from show_regs, however this can be cumbersome to do if you don't have the vmlinux to verify with the address of cpu_pda, how about the following? I considered using hard_smp_processor_id for robustness but we already dereference current so we're already relying on MSR_GS_BASE being sane. Signed-off-by:
Zwane Mwaikambo <zwane@arm.linux.org.uk> Acked-by:
-
Ashok Raj authored
When handling writes to /proc/irq, current code is re-programming rte entries directly. This is not recommended and could potentially cause chipset's to lockup, or cause missing interrupts. CONFIG_IRQ_BALANCE does this correctly, where it re-programs only when the interrupt is pending. The same needs to be done for /proc/irq handling as well. Otherwise user space irq balancers are really not doing the right thing. - Changed pending_irq_balance_cpumask to pending_irq_migrate_cpumask for lack of a generic name. - added move_irq out of IRQ_BALANCE, and added this same to X86_64 - Added new proc handler for write, so we can do deferred write at irq handling time. - Display of /proc/irq/XX/smp_affinity used to display CPU_MASKALL, instead it now shows only active cpu masks, or exactly what was set. - Provided a common move_irq implementation, instead of duplicating when using generic irq framework. Tested on i386/x86_64 and ia64 with CONFIG_PCI_MSI turned on and off. Tested UP builds as well. MSI testing: tbd: I have cards, need to look for a x-over cable, although I did test an earlier version of this patch. Will test in a couple days. Signed-off-by:
Zwane Mwaikambo <zwane@holomorphy.com> Grudgingly-acked-by:
Coywolf Qi Hunt <coywolf@lovecn.org> Signed-off-by:
-
Eugene Surovegin authored
Add sysfs node for ocp_func_emac_data.phy_feat_exc field. Signed-off-by:
Eugene Surovegin <ebs@ebshome.net> Signed-off-by:
-
Eugene Surovegin authored
Recent "u32 -> pm_message_t" change triggered hidden bug in ocp_device_suspend. Fix it to correctly use pm_message_t instead of u32. Signed-off-by:
-
- 06 Sep, 2005 29 commits
-
-
Linus Torvalds authored
-
Linus Torvalds authored
-
Linus Torvalds authored
-
Linus Torvalds authored
-
Linus Torvalds authored
-
Linus Torvalds authored
-
Linus Torvalds authored
-
Olaf Hering authored
Changing CONFIG_LOCALVERSION rebuilds too much, for no apparent reason. Use system_utsname for progress and debug header. Signed-off-by:
Olaf Hering <olh@suse.de> Signed-off-by:
Paul Mackerras <paulus@samba.org>
-
David Gibson authored
Currently, we set the class bit in kernel SLB entries, and clear it on user SLB entries. On POWER5, ERAT entries created in real mode have the class bit clear. So to avoid flushing kernel ERAT entries on each context switch, this patch inverts our usage of the class bit, setting it on user SLB entries and clearing it on kernel SLB entries. Booted on POWER5 and G5. Signed-off-by:
David Gibson <dwg@au1.ibm.com> Signed-off-by:
-
Al Viro authored
Yet another architecture not coverd by GEN_RTC - sparc64 never picked it until now and it doesn't have asm/rtc.h to go with it, so it wouldn't compile anyway (or have these ioctls in the user-visible headers, for that matter). FWIW, I'm very tempted to introduce ARCH_HAS_GEN_RTC and have it set in arch/*/Kconfig for architectures that know what to do with this stuff - for something supposedly generic the list of architectures where it doesn't work is getting too long... Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
Al Viro authored
sunsu had been broken by ->stop_tx/->start_tx API changes. Signed-off-by:
-
David S. Miller authored
It's really not relevant for this platform in any way, after all. Signed-off-by: -
David S. Miller authored
Based upon a report from Jason Wever. Signed-off-by: -
Al Viro authored
Actually, proper fix of that breakage is embarrassingly simple - it's yet another gratitious leftover include of asm/segment.h, so incremental to the previos would be removal of that BROKEN and removal of bogus include from mxser.c itself. Signed-off-by: -
David S. Miller authored
Signed-off-by: -
Anton Blanchard authored
Fix build with oprofile disabled. Signed-off-by:
Anton Blanchard <anton@samba.org> Signed-off-by:
-
Anton Blanchard authored
Move oprofile_model into cpu feature struct. Signed-off-by:
-
Anton Blanchard authored
Move oprofile_impl.h into include/asm-ppc64 in preparation for moving oprofile_model into cpu feature struct. Signed-off-by:
-
Anton Blanchard authored
Add oprofile cpu_type to cpu feature struct. Signed-off-by:
-
Anton Blanchard authored
Change oprofile to use num_pmcs from the cpu feature struct. Signed-off-by:
-
Anton Blanchard authored
Remove the CPU_FTR_PMC8 feature now we encode the number of PMCs directly. Signed-off-by:
-
Anton Blanchard authored
Add a field in the cputable struct to store the number of PMCs. Signed-off-by:
-
David S. Miller authored
Signed-off-by: -
Wim Coekaerts authored
I would like to be able to read the lparcfg data from any user so we can make "intelligent" decisions based on underlying attributes when running in lpars. Yes there's software that likes to do this :) and runs as non-root. It's very similar to say VM where you can get CP to provide feedback of the real hardware inside a VM guest. Signed-off-by:
Wim Coekaerts <wim.coekaerts@oracle.com> Signed-off-by:
-
Kumar Gala authored
Removed PPC64 architecture specific users of asm/segment.h. Signed-off-by:
Kumar Gala <kumar.gala@freescale.com> Signed-off-by:
-
Jon Loeliger authored
This patch merges several include files from asm-ppc and asm-ppc64 into the new asm-powerpc. Signed-off-by:
Jon Loeliger <jdl@freescale.com> Signed-off-by:
-
Becky Bruce authored
Merged several nearly-identical header files from asm-ppc and asm-ppc64 into asm-powerpc. Signed-off-by:
Becky Bruce <becky.bruce@freescale.com> Signed-off-by:
-
Anton Blanchard authored
cmpxchg has the following code: __typeof__(*(ptr)) _o_ = (o); __typeof__(*(ptr)) _n_ = (n); Unfortunately it makes gcc 4.0 store and load the variables to the stack. Eg in atomic_dec_and_test we get: stw r10,112(r1) stw r9,116(r1) lwz r9,112(r1) lwz r0,116(r1) x86 is just casting the values so do that instead. Also change __xchg* and __cmpxchg* to take unsigned values, removing a few sign extensions. Signed-off-by:
-
Anton Blanchard authored
Poison initmem after we free it so we catch use after free issues. Signed-off-by:
-
