Thread (21 messages) 21 messages, 8 authors, 2015-12-10

Re: [PATCH 2/2] mm/page_ref: add tracepoint to track down page reference manipulation

From: Steven Rostedt <rostedt@goodmis.org>
Date: 2015-12-09 20:02:08
Also in: linux-mm, lkml

On Thu, 3 Dec 2015 13:16:58 +0900
Joonsoo Kim [off-list ref] wrote:
On Tue, Nov 24, 2015 at 10:45:28AM +0900, Joonsoo Kim wrote:
quoted
On Mon, Nov 23, 2015 at 09:26:04AM -0500, Steven Rostedt wrote:  
quoted
On Mon, 23 Nov 2015 17:28:05 +0900
Joonsoo Kim [off-list ref] wrote:
  
quoted
On Fri, Nov 20, 2015 at 11:42:25AM -0500, Steven Rostedt wrote:  
quoted
On Fri, 20 Nov 2015 15:33:25 +0900
Joonsoo Kim [off-list ref] wrote:

    
quoted
Steven, is it possible to add tracepoint to inlined fucntion such as
get_page() in include/linux/mm.h?    
I highly recommend against it. The tracepoint code adds a bit of bloat,
and if you inline it, you add that bloat to every use case. Also, it    
Is it worse than adding function call to my own stub function into
inlined function such as get_page(). I implemented it as following.

get_page()
{
        atomic_inc()
        stub_get_page()
}

stub_get_page() in foo.c
{
        trace_page_ref_get_page()
}  
Now you just slowed down the fast path. But what you could do is:

get_page()
{
	atomic_inc();
	if (trace_page_ref_get_page_enabled())
		stub_get_page();
}

Now that "trace_page_ref_get_page_enabled()" will turn into:

	if (static_key_false(&__tracepoint_page_ref_get_page.key)) {

which is a jump label (nop when disabled, a jmp when enabled). That's
less bloat but doesn't solve the include problem. You still need to add
the include of that will cause havoc with other tracepoints.  
Yes, It also has a include dependency problem so I can't use
trace_page_ref_get_page_enabled() in mm.h. BTW, I tested following
implementation and it works fine.

extern struct tracepoint __tracepoint_page_ref_get_page;

get_page()
{
        atomic_inc()
        if (static_key_false(&__tracepoint_page_ref_get_page.key))
                stub_get_page()
}

This would not slow down fast path although it can't prevent bloat.
I know that it isn't good code practice, but, this page reference
handling functions have complex include dependency so I'm not sure
I can solve it completely. For this special case, can I use
this raw data structure?
  
Steven, any comment?
Sorry for the later reply, I was going to reply but then got called off
to do something else, and then forgot about this message :-/

I wanted you to look at what Andi has done here:

http://lkml.kernel.org/r/1449018060-1742-2-git-send-email-andi@firstfloor.org

 and here

http://lkml.kernel.org/r/1449018060-1742-3-git-send-email-andi@firstfloor.org

-- Steve

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help