Re: [PATCH 3/3] tracing: Rewrite filter logic to be simpler and faster

On Fri, 9 Mar 2018 22:15:23 -0500 Steven Rostedt <rost...@goodmis.org> wrote: > Sorry for the spam. A little more spam ;-) I know what happened, as I'm able to recreate it. For those that use claws-mail, be careful. I clicked on the email I wanted to reply to. Then I must have hit

Re: [PATCH 3/3] tracing: Rewrite filter logic to be simpler and faster

logic on literals in min()/max()". Sorry for the spam. -- Steve On Fri, 9 Mar 2018 22:10:19 -0500 Steven Rostedt <rost...@goodmis.org> wrote: > On Fri, 09 Mar 2018 21:34:45 -0500 > Steven Rostedt <rost...@goodmis.org> wrote: > > > 2 files changed, 1050 insert

Re: [PATCH 3/3] tracing: Rewrite filter logic to be simpler and faster

On Fri, 09 Mar 2018 21:34:45 -0500 Steven Rostedt <rost...@goodmis.org> wrote: > 2 files changed, 1050 insertions(+), 1273 deletions(-) BTW, it's a bit bigger impact than 223 deletions. As I added a lot of comments to explain the logic better. Removing comments and white s

Re: [PATCH 0/3] Remove accidental VLA usage

On Thu, 8 Mar 2018 09:02:36 -0600 Josh Poimboeuf wrote: > On Wed, Mar 07, 2018 at 07:30:44PM -0800, Kees Cook wrote: > > This series adds SIMPLE_MAX() to be used in places where a stack array > > is actually fixed, but the compiler still warns about VLA usage due to > >

Re: [RFC PATCH bpf-next v2 1/4] tracing/kprobe: bpf: Check error injectable event is on function entry

On Wed, 27 Dec 2017 19:45:42 -0800 Alexei Starovoitov wrote: > I don't think that's the case. My reading of current > trace_kprobe_ftrace() -> arch_check_ftrace_location() > is that it will not be true for old mcount case. In the old mcount case, you can't use ftrace to return

Re: [PATCH 01/14] VFS: Don't use save/replace_mount_options if not using generic_show_options

On Wed, 05 Jul 2017 16:33:29 +0100 David Howells <dhowe...@redhat.com> wrote: > Steven Rostedt <rost...@goodmis.org> wrote: > > > As this is patch 1/14, is there any dependency on this working? That > > is, it is safe to simply remove th

Re: [PATCH 01/14] VFS: Don't use save/replace_mount_options if not using generic_show_options

On Wed, 05 Jul 2017 16:24:09 +0100 David Howells wrote: > btrfs, debugfs, reiserfs and tracefs call save_mount_options() and reiserfs > calls replace_mount_options(), but they then implement their own > ->show_options() methods and don't touch s_options, rendering the saved

Re: [PATCH 02/12] trace: Make trace_hwlat timestamp y2038 safe

+4,6 @@ > * Copyright (C) 2008 Red Hat Inc, Steven Rostedt <srost...@redhat.com> > * > */ > - > #include > #include > #include > @@ -1161,11 +1160,11 @@ trace_hwlat_print(struct trace_iterator *iter, int > flags, > > trace_assign_type(fi

Re: btrfs_destroy_inode warn (outstanding extents)

On Thu, Dec 01, 2016 at 10:32:09AM -0500, Dave Jones wrote: > > (function-graph screws up the RIP for some reason, 'return_to_handler' > should actually be btrfs_destroy_inode) That's because function_graph hijacks the return address and replaces it with return_to_handler. The back trace has

Re: [PATCH v2 1/2] Return a value from printk_ratelimited

On Fri, 19 Sep 2014 02:01:29 -0700 Omar Sandoval osan...@osandov.com wrote: printk returns an integer; there's no reason for printk_ratelimited to swallow it. Signed-off-by: Omar Sandoval osan...@osandov.com --- include/linux/printk.h | 4 +++- 1 file changed, 3 insertions(+), 1

[PATCH] btrfs: Use trace condition for get_extent tracepoint

-by: Steven Rostedt rost...@goodmis.org diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c index 51e3afa..a9ad918 100644 --- a/fs/btrfs/inode.c +++ b/fs/btrfs/inode.c @@ -6173,8 +6173,7 @@ insert: write_unlock(em_tree-lock); out: - if (em) - trace_btrfs_get_extent(root, em

Re: [PATCH 1/2] tracing: add __print_symbolic_u64 to avoid warnings on 32bit machine

On Thu, 2011-05-26 at 01:49 -0400, liubo wrote: On 05/01/2011 11:35 AM, Steven Rostedt wrote: On Fri, 2011-04-29 at 18:01 +0800, liubo wrote: ping? Sorry, I've been trying to get the new ftrace function tracer features out ASAP. I plan on looking at this when I'm done. Thanks

Re: [PATCH 1/2] tracing: add __print_symbolic_u64 to avoid warnings on 32bit machine

On Wed, 2011-05-25 at 09:12 -0700, Randy Dunlap wrote: But what I sent out previously is not going into 2.6.40 anyway. Ingo feels that it's too late in the merge window to pull those changes and wants to wait till the next merge window. Since there's some fixes in that pull request,

Re: [PATCH 1/2] tracing: add __print_symbolic_u64 to avoid warnings on 32bit machine

On Fri, 2011-04-29 at 18:01 +0800, liubo wrote: ping? Sorry, I've been trying to get the new ftrace function tracer features out ASAP. I plan on looking at this when I'm done. Thanks, -- Steve On 04/19/2011 09:35 AM, liubo wrote: Filesystem, like Btrfs, has some ULL macros, and when

Re: [PATCH] Trace: add __print_symbolic_u64 to avoid warnings on 32bit machine

On Wed, 2011-04-06 at 17:18 +0800, liubo wrote: Btrfs has some ULL macros, and when these macros are passed to tracepoints' __print_symbolic(), there will be 64-32 truncate WARNINGS during compiling on 32bit box. Signed-off-by: Liu Bo liubo2...@cn.fujitsu.com ---

Re: [RFC PATCH] Trace: use unsigned long long in trace print frames

On Fri, 2011-04-01 at 14:42 +0800, liubo wrote: While adding tracepoint for btrfs, I got a problem: btrfs uses some macros with ULL type, but tracepoint's macros, __print_[flags,symbols](), only have unsigned long, so on 32bit box there will be 64-32 truncate WARNINGs when compiling. Here

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

On Fri, 2011-03-25 at 07:53 +0100, Tejun Heo wrote: Hello, Steven, Linus. On Thu, Mar 24, 2011 at 09:38:58PM -0700, Linus Torvalds wrote: On Thu, Mar 24, 2011 at 8:39 PM, Steven Rostedt rost...@goodmis.org wrote: But now, mutex_trylock(B) becomes a spinner too, and since the B's owner

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

On Fri, 2011-03-25 at 14:13 +0300, Andrey Kuzmin wrote: Turning try_lock into indefinitely spinning one breaks its semantics, so deadlock is to be expected. But what's wrong in this scenario if try_lock spins a bit before giving up? Because that will cause this scenario to spin that little

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

On Fri, 2011-03-25 at 09:10 -0400, Steven Rostedt wrote: One solution is to have this be only done on explicit trylocks. Perhaps introduce a mutex_trylock_spin()? Then when the developer knows that this scenario does not exist, they can convert mutex_trylocks() into this spinning version

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

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 its semantics, so deadlock is to be expected

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

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? -- Steve -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the

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

On Thu, Mar 24, 2011 at 10:41:51AM +0100, Tejun Heo wrote: Adaptive owner spinning used to be applied only to mutex_lock(). This patch applies it also to mutex_trylock(). btrfs has developed custom locking to avoid excessive context switches in its btree implementation. Generally, doing

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

On Fri, 9 Jan 2009, Peter Zijlstra wrote: On Fri, 2009-01-09 at 11:47 +0100, Peter Zijlstra wrote: So I think the bug is still there, we just hid it better by breaking out of the loop with that if (need_resched()) always eventually triggering. And it would be ok if it really is

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

On Fri, 9 Jan 2009, H. Peter Anvin wrote: Dirk Hohndel wrote: Does gcc actually follow the promise? If that's the case (and if it's considered a bug when it doesn't), then we can get what Linus wants by annotating EVERY function with either __always_inline or noinline.

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

On Fri, 9 Jan 2009, Theodore Tso wrote: I'm beginning to think that for the kernel, we should just simply remove CONFIG_OPTIMIZE_INLINING (so that inline means always_inline), and -fno-inline-functions -fno-inline-functions-called-one (so that gcc never inlines functions behind our back)

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

- Headers could probably go back to 'extern inline' again. At not small expense - we just finished moving to 'static inline'. We'd need to guarantee a library instantiation for every header include file - this is an additional mechanism with additional introduction complexities

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

On Thu, 8 Jan 2009, Andi Kleen wrote: What about memory hotplug as Ingo mentioned? Should that be: #if defined(CONFIG_DEBUG_PAGEALLOC) || defined(CONFIG_MEMORY_HOTPLUG) We expect memory hotunplug to only really work in movable zones (all others should at least have one kernel

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

On Thu, 8 Jan 2009, Steven Rostedt wrote: + /* +* We need to validate that we can do a +* get_cpu() and that we have the percpu area. +*/ + if (!cpu_online(cpu)) + goto out; Should we need to do a get_cpu

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

On Thu, 8 Jan 2009, Linus Torvalds wrote: And I don't even believe that is the bug. I suspect the bug is simpler. I think the need_resched() needs to go in the outer loop, or at least happen in the !owner case. Because at least with preemption, what can happen otherwise is -

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

On Thu, 8 Jan 2009, Steven Rostedt wrote: In fact, you might not even need a process C: all you need is for B to be on the same runqueue as A, and having enough load on the other CPU's that A never gets migrated away. So C might be in user space. You're right about not needing process

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

On Thu, 8 Jan 2009, Chris Mason wrote: On Thu, 2009-01-08 at 13:14 -0500, Steven Rostedt wrote: If it was the current process that preempted the owner and these are RT tasks pinned to the same CPU and the owner is of lower priority than the spinner, we have a deadlock! Hmm, I do

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

The problem? Setting lock-count to 0. That will mean that the next mutex_unlock() will not necessarily enter the slowpath at all, and won't necessarily wake things up like it should. Normally we set lock-count to 0 after getting the lock, and only _inside_ the spinlock, and then we

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

On Wed, 7 Jan 2009, Steven Rostedt wrote: On Wed, 7 Jan 2009, Peter Zijlstra wrote: --- a/kernel/mutex.c +++ b/kernel/mutex.c @@ -10,6 +10,10 @@ * Many thanks to Arjan van de Ven, Thomas Gleixner, Steven Rostedt and * David Howells for suggestions and improvements

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

On Wed, 7 Jan 2009, Linus Torvalds wrote: So we can do all that locklessly and optimistically, just going back and verifying the results later. This is why thread_info is actually a better thing to use than task_struct - we can look up the cpu in it with a simple dereference. We knew the

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

On Wed, 7 Jan 2009, Gregory Haskins wrote: Hi Ingo, Ingo Molnar wrote: * Gregory Haskins ghask...@novell.com wrote: Can I ask a simple question in light of all this discussion? Is get_task_struct() really that bad? it dirties a cacheline and it also involves

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

On Wed, 7 Jan 2009, Steven Rostedt wrote: True. I need to keep looking at the code that is posted. In -rt, we force the fast path into the slowpath as soon as another task fails to get the lock. Without that, as you pointed out, the code can be racy. I mean we force the fast unlock path

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

On Wed, 7 Jan 2009, Linus Torvalds wrote: Should that be: #if defined(CONFIG_DEBUG_PAGEALLOC) || defined(CONFIG_MEMORY_HOTPLUG) Well, probably CONFIG_MEMORY_HOTREMOVE, no? And I'd actually suggest that unplugging should have a stop-machine if it doesn't already, just because it's