Re: [PATCH v3] kernel.h: Skip single-eval logic on literals in min()/max()

* Linus Torvalds wrote: > So an error message like > >warning: ISO C90 requires array sizes to be constant-expressions > > would be technically correct and useful from a portability angle. It > tells you when you're doing something non-portable, and should

Re: [PATCH 2/4] btrfs: make open_ctree error injectable

lot better - except the random header inclusion dependency: if a facility is in the BPF_*() namespace then it should include and not a random asm/* header... With that detail fixed: Acked-by: Ingo Molnar <mi...@kernel.org> for the whole series. Thanks, Ingo -- To unsubscribe from t

Re: bio linked list corruption.

* Peter Zijlstra wrote: > $ git grep DECLARE_WAIT_QUEUE_HEAD_ONSTACK | wc -l > 28 This debug facility looks sensible. A couple of minor suggestions: > --- a/include/linux/wait.h > +++ b/include/linux/wait.h > @@ -39,6 +39,9 @@ struct wait_bit_queue { > struct

Re: bio linked list corruption.

* Linus Torvalds wrote: > On Wed, Oct 19, 2016 at 10:09 AM, Philipp Hahn wrote: > > > > Nearly a month ago I reported also a "list_add corruption", but with 4.1.6: > > > > > > That server

Re: [PATCH 2/2] Btrfs: stop caching thread if extetn_commit_sem is contended

* Josef Bacik jba...@fusionio.com wrote: On Fri, Sep 20, 2013 at 07:12:47AM +0200, Ingo Molnar wrote: * Josef Bacik jba...@fusionio.com wrote: We can starve out the transaction commit with a bunch of caching threads all running at the same time. This is because we will only drop

Re: [PATCH 1/2] rwsem: add rwsem_is_contended V3

% accurate and called by somebody already holding on to the rwsem in either read or write. Thanks, Signed-off-by: Josef Bacik jba...@fusionio.com Acked-by: Ingo Molnar mi...@kernel.org Thanks, Ingo -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body

Re: [PATCH 2/2] Btrfs: stop caching thread if extetn_commit_sem is contended

. This should answer akpm's concern I think. If this analysis is correct then: Acked-by: Ingo Molnar mi...@kernel.org Thanks, Ingo -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http

Re: [PATCH] rwsem: add rwsem_is_contended

* Andrew Morton a...@linux-foundation.org wrote: On Fri, 30 Aug 2013 10:14:01 -0400 Josef Bacik jba...@fusionio.com wrote: Btrfs uses an rwsem to control access to its extent tree. Threads will hold a read lock on this rwsem while they scan the extent tree, and if need_resched() they

Re: [PATCH] Btrfs: fix 64 bit divide problem

the counters u64 to match up with rw_devices. Thanks, Signed-off-by: Josef Bacik jo...@redhat.com Acked-and-tested-by: Ingo Molnar mi...@elte.hu Thanks, Ingo -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More

Re: [RFC PATCH] mutex: Apply adaptive spinning on mutex_trylock()

* Steven Rostedt rost...@goodmis.org wrote: On Thu, Mar 24, 2011 at 09:18:16AM +0100, Ingo Molnar wrote: * Tejun Heo t...@kernel.org wrote: NOT-Signed-off-by: Tejun Heo t...@kernel.org s/NOT-// ? Perhaps because it is still in RFC context? Ok, i guess i was a bit too

Re: [PATCH 2/2] mutex: Apply adaptive spinning on mutex_trylock()

* Tejun Heo t...@kernel.org wrote: Hello, On Thu, Mar 24, 2011 at 10:41:51AM +0100, Tejun Heo wrote: USER SYSTEM SIRQCXTSW THROUGHPUT SIMPLE 61107 354977217 8099529 845.100 MB/sec SPIN 63140 364888214 6840527 879.077 MB/sec On various runs, the

Re: [PATCH 2/2] mutex: Apply adaptive spinning on mutex_trylock()

* Steven Rostedt rost...@goodmis.org wrote: On Fri, 2011-03-25 at 16:50 +0300, Andrey Kuzmin wrote: On Fri, Mar 25, 2011 at 4:12 PM, Steven Rostedt rost...@goodmis.org wrote: On Fri, 2011-03-25 at 14:13 +0300, Andrey Kuzmin wrote: Turning try_lock into indefinitely spinning one breaks

Re: [RFC PATCH] mutex: Apply adaptive spinning on mutex_trylock()

* Tejun Heo t...@kernel.org wrote: NOT-Signed-off-by: Tejun Heo t...@kernel.org s/NOT-// ? Ingo -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at

Re: [PATCH V2 0/3] improve the performance of some memory copy functions

* Miao Xie mi...@cn.fujitsu.com wrote: - change the version of GPL from version 2.1 to version 2 How were you able to do this? If the code derives from glibc (as your comments in the patches suggest), and if glibc is under the GPL v2.1, then you probably cannot simply change the license to

Re: [GIT PULL] adaptive spinning mutexes

* Chris Mason chris.ma...@oracle.com wrote: On Wed, 2009-01-14 at 19:33 +0100, Ingo Molnar wrote: * Peter Zijlstra pet...@infradead.org wrote: Full series, including changelogs available at: http://programming.kicks-ass.net/kernel-patches/mutex-adaptive-spin/ and should

Re: [GIT PULL] adaptive spinning mutexes

* Matthew Wilcox matt...@wil.cx wrote: On Wed, Jan 14, 2009 at 08:28:11PM +0100, Ingo Molnar wrote: [v2.6.14] [v2.6.29] Semaphores | Mutexes

Re: [GIT PULL] adaptive spinning mutexes

* Linus Torvalds torva...@linux-foundation.org wrote: Has anyone found a non-synthetic benchmark where this makes a significant difference? Aside from btrfs, I mean. Yea, if you have some particular filesystem (or other subsystem) that uses a global mutex, you'll obviously see way

Re: [GIT PULL] adaptive spinning mutexes

* Chris Mason chris.ma...@oracle.com wrote: [ re: pipes, ok I don't know of realistic pipe benchmarks but I'll run them if people can suggest one ] Threaded servers making heavy use of sys_splice() ought to hit the pipe mutex all the time. Ingo -- To unsubscribe from this list:

Re: [PATCH -v9][RFC] mutex: implement adaptive spinning

* Chris Mason chris.ma...@oracle.com wrote: v10 is better that not spinning, but its in the 5-10% range. So, I've been trying to find ways to close the gap, just to understand exactly where it is different. If I take out: /* * If there are pending waiters, join them.

[PATCH -v11 delta] mutex: implement adaptive spinning

* Linus Torvalds torva...@linux-foundation.org wrote: If I take out: /* * If there are pending waiters, join them. */ if (!list_empty(lock-wait_list)) break; v10 pops dbench 50 up to 1800MB/s. The other tests soundly beat my spinning and

[GIT PULL] adaptive spinning mutexes

* Peter Zijlstra pet...@infradead.org wrote: Full series, including changelogs available at: http://programming.kicks-ass.net/kernel-patches/mutex-adaptive-spin/ and should shortly appear in a git tree near Ingo :-) Linus, Please pull the adaptive-mutexes-for-linus git tree from:

Re: [GIT PULL] adaptive spinning mutexes

* Ingo Molnar mi...@elte.hu wrote: Linus, Please pull the adaptive-mutexes-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git adaptive-mutexes-for-linus We dropped two fresh patches from v11 for the time being: the two debug patches

Re: [GIT PULL] adaptive spinning mutexes

* Peter Zijlstra a.p.zijls...@chello.nl wrote: On Wed, 2009-01-14 at 10:53 -0800, Andrew Morton wrote: On Wed, 14 Jan 2009 19:33:19 +0100 Ingo Molnar mi...@elte.hu wrote: Please pull the adaptive-mutexes-for-linus git tree fear - It seems a major shortcoming that the feature

Re: [GIT PULL] adaptive spinning mutexes

* Andrew Morton a...@linux-foundation.org wrote: On Wed, 14 Jan 2009 20:00:08 +0100 Ingo Molnar mi...@elte.hu wrote: * Andrew Morton a...@linux-foundation.org wrote: On Wed, 14 Jan 2009 19:33:19 +0100 Ingo Molnar mi...@elte.hu wrote: Please pull the adaptive-mutexes

Re: [GIT PULL] adaptive spinning mutexes

* Peter Zijlstra a.p.zijls...@chello.nl wrote: On Wed, 2009-01-14 at 11:36 -0800, Andrew Morton wrote: Do people enable CONFIG_SCHED_DEBUG? Well, I have it always enabled, but I've honestly no idea if that makes me weird. CONFIG_DEBUG_MUTEXES=n, CONFIG_SCHED_DEBUG=y is getting to be

Re: [GIT PULL] adaptive spinning mutexes

* Andrew Morton a...@linux-foundation.org wrote: Do people enable CONFIG_SCHED_DEBUG? If they suspect performance problems and want to analyze them? The vast majority of users do not and usually cannot compile their own kernels. ... which they derive from distro kernels or some old

Re: [GIT PULL] adaptive spinning mutexes

* Ingo Molnar mi...@elte.hu wrote: You just disproved your own case :( how so? 80% is not enough? I also checked Fedora and it has SCHED_DEBUG=y in its kernel rpms. Ubuntu has CONFIG_SCHED_DEBUG=y as well in their kernels. note that there's also a performance issue here: we generally

Re: [GIT PULL] adaptive spinning mutexes

* Kay Sievers kay.siev...@vrfy.org wrote: On Wed, Jan 14, 2009 at 22:41, Ingo Molnar mi...@elte.hu wrote: * Ingo Molnar mi...@elte.hu wrote: You just disproved your own case :( how so? 80% is not enough? I also checked Fedora and it has SCHED_DEBUG=y in its kernel rpms

Re: [GIT PULL] adaptive spinning mutexes

* Andrew Morton a...@linux-foundation.org wrote: I also checked Fedora and it has SCHED_DEBUG=y in its kernel rpms. If all distros set SCHED_DEBUG=y then fine. 95% of the distros and significant majority of the lkml traffic. And no, we dont generally dont provide knobs for essential

Re: [PATCH -v9][RFC] mutex: implement adaptive spinning

* Peter Zijlstra pet...@infradead.org wrote: Now you're forcing the slow-path on unlock. Maybe it was intentional, maybe it wasn't. Did you perhaps mean if (atomic_cmpxchg(lock-count, 1, 0) == 1) { here? I thought we agreed it was safe, if only because it should be

Re: [PATCH -v9][RFC] mutex: implement adaptive spinning

* Linus Torvalds torva...@linux-foundation.org wrote: On Tue, 13 Jan 2009, Ingo Molnar wrote: And v8 is rock solid in all my testing - and i'll give v10 a similar workout as well. The differences between v8 and v10 are very fundamental, since v8 does the spinning inside

Re: [PATCH -v9][RFC] mutex: implement adaptive spinning

This command re-enables spinning again (this is also the default): # echo OWNER_SPIN /debug/sched_features Changes since -v9: - cmpxchg acquire in the spin loop Changes since -v8: - dropped the fairness Signed-off-by: Peter Zijlstra a.p.zijls...@chello.nl Signed-off-by: Ingo Molnar mi

Re: [PATCH -v9][RFC] mutex: implement adaptive spinning

* Linus Torvalds torva...@linux-foundation.org wrote: On Tue, 13 Jan 2009, Ingo Molnar wrote: below is the v8 - v10 delta patch - for all who'd like to review the changes. Hmm. This does seem to indicate that v10 lost many of the preempt changes. Probably because Peter went

Re: [PATCH -v7][RFC]: mutex: implement adaptive spinning

* Jamie Lokier ja...@shareable.org wrote: Ingo Molnar wrote: If it's used once in a single .c file it should be inlined even if it's large. As Linus has pointed out, because of GCC not sharing stack among different inlined functions, the above is surprisingly not true. Yes, but note

Re: source line numbers with x86_64 modules? [Was: Re: [patch] measurements, numbers about CONFIG_OPTIMIZE_INLINING=y impact]

* Linus Torvalds torva...@linux-foundation.org wrote: As far as I'm concerned, digital cameras have been more useful than kernel dumps to kernel debugging. Yes, especially ones with VGA video capture. (I caught a oops+triple-fault crash via that trick once, which was not serial-console

[patch] measurements, numbers about CONFIG_OPTIMIZE_INLINING=y impact

- the size win from inline-optimization is significant: 1% for defconfig, 3% for allyesconfig and 7.5% for the core kernel (allyesconfig). Ingo -- Subject: asm: inline bitops constant set From: Ingo Molnar mi...@elte.hu Date: Fri Jan 09 11:43:20 CET 2009 Signed-off

Re: [PATCH -v7][RFC]: mutex: implement adaptive spinning

* H. Peter Anvin h...@zytor.com wrote: Andi Kleen wrote: I'll try to annotate the inline asms (there's not _that_ many of them), and measure what the size impact is. You can just use the patch I submitted and that you rejected for most of them :) I just ran a sample build for

Re: [patch] measurements, numbers about CONFIG_OPTIMIZE_INLINING=y impact

* jim owens jow...@hp.com wrote: Ingo Molnar wrote: One interpretation of the numbers would be that core kernel hackers are more inline-happy, maybe because they think that their functions are more important to inline. Which is generally a fair initial assumption, but according

Re: [PATCH -v7][RFC]: mutex: implement adaptive spinning

* Linus Torvalds torva...@linux-foundation.org wrote: On Fri, 9 Jan 2009, Ingo Molnar wrote: So, should we not remove CONFIG_OPTIMIZE_INLINING, then the correct one would be to mark it __always_inline [__asm_inline is senseless there], or the second patch below that changes the bit

Re: [PATCH -v7][RFC]: mutex: implement adaptive spinning

* Linus Torvalds torva...@linux-foundation.org wrote: On Fri, 9 Jan 2009, Ingo Molnar wrote: So, should we not remove CONFIG_OPTIMIZE_INLINING, then the correct one would be to mark it __always_inline [__asm_inline is senseless there], or the second patch below that changes the bit

Re: [PATCH -v7][RFC]: mutex: implement adaptive spinning

* Linus Torvalds torva...@linux-foundation.org wrote: On Fri, 9 Jan 2009, Harvey Harrison wrote: __needs_inline? That would imply that it's for correctness reasons. .. but the point is, we have _thousands_ of inlines, and do you know which is which? We've historically forced them to

Re: [PATCH -v7][RFC]: mutex: implement adaptive spinning

* Linus Torvalds torva...@linux-foundation.org wrote: Unrelated: On Thu, 8 Jan 2009, Chris Mason wrote: RIP: 0010:[8024f4de] [8024f4de] __cmpxchg+0x36/0x3f Ouch. HOW THE HELL DID THAT NOT GET INLINED? cmpxchg() is a _single_ instruction if it's inlined, but it's a

Re: Btrfs for mainline

* Chris Mason chris.ma...@oracle.com wrote: On Tue, 2009-01-06 at 01:47 +1100, Nick Piggin wrote: [ adaptive locking in btrfs ] adaptive locks have traditionally (read: Linus says) indicated the locking is suboptimal from a performance perspective and should be reworked. This is

Re: Btrfs for mainline

* Matthew Wilcox matt...@wil.cx wrote: On Wed, Jan 07, 2009 at 02:07:42PM +0100, Ingo Molnar wrote: * Chris Mason chris.ma...@oracle.com wrote: All of this is a long way of saying the btrfs locking scheme is far from perfect. I'll look harder at the loop and ways to get rid

Re: [PATCH -v5][RFC]: mutex: implement adaptive spinning

* Linus Torvalds torva...@linux-foundation.org wrote: /* * Even if the access succeeded (likely case), * the cpu field may no longer be valid. FIXME: * this needs to validate that we can do a

Re: [PATCH -v5][RFC]: mutex: implement adaptive spinning

* Andrew Morton a...@linux-foundation.org wrote: On Wed, 7 Jan 2009 22:32:22 +0100 Ingo Molnar mi...@elte.hu wrote: We could do the whole oldfs = get_fs(); set_fs(KERNEL_DS); .. set_fs(oldfs); crud, but it would probably be better to just add an architected accessor. Especially

Re: [PATCH][RFC]: mutex: adaptive spin

* Ingo Molnar mi...@elte.hu wrote: One thought: BUG_ON()'s do_exit() shows a slightly misleading failure pattern to users: instead of a 'hanging' task, we'd get a misbehaving app due to one of its tasks exiting spuriously. It can even go completely unnoticed [users dont look at kernel

Re: [PATCH][RFC]: mutex: adaptive spin

* Linus Torvalds torva...@linux-foundation.org wrote: On Tue, 6 Jan 2009, Linus Torvalds wrote: Right now, if some process deadlocks on a mutex, we get hung process, but with a nice backtrace and hopefully other things (that don't need that lock) still continue to work.