All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
To: Srinivasa D S <srinivasa@in.ibm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org, mhiramat@redhat.com,
	jkenisto@us.ibm.com, srikar@linux.vnet.ibm.com
Subject: Re: [RFC] [PATCH] To improve kretprobe scalability
Date: Tue, 27 May 2008 13:52:42 +0530	[thread overview]
Message-ID: <20080527082242.GA3473@in.ibm.com> (raw)
In-Reply-To: <200805221356.40098.srinivasa@in.ibm.com>

On Thu, May 22, 2008 at 01:56:39PM +0530, Srinivasa D S wrote:
> On Thursday 22 May 2008 05:02:35 am Andrew Morton wrote:
> > On Wed, 21 May 2008 06:32:17 +0530
> >
> > Srinivasa D S <srinivasa@in.ibm.com> wrote:

...
 
> Resending the patch, Again
> 
> 
> Currently list of kretprobe instances are stored in kretprobe object (as
> used_instances,free_instances) and in kretprobe hash table. We have one 
> global kretprobe lock to serialise the access to these lists. This causes 
> only one kretprobe handler to execute at a time. Hence affects system 
> performance, particularly on SMP systems and when return probe is set on
> lot of functions (like on all systemcalls).
> 
> Solution proposed here gives fine-grain locks that performs better on SMP
> system compared to present kretprobe implementation.
> 
> Solution:
>    1) Instead of having one global lock to protect kretprobe instances  
> present 
> in kretprobe object and kretprobe hash table. We will have two locks, one lock
> for protecting kretprobe hash table and another lock for kretporbe object.
> 	
>   2) We hold lock present in kretprobe object while we modify kretprobe 
> instance in
> kretprobe object and we hold per-hash-list lock while modifying kretprobe 
> instances 
> present in that hash list. To prevent deadlock, we never grab a per-hash-list
> lock while holding a kretprobe lock.
> 
>   3) We can remove used_instances from struct kretprobe, as we can track used
> instances of kretprobe instances using kretprobe hash table.
> 
> Time duration for  kernel compilation ("make -j 8") on a 8-way ppc64 system
> with return probes set on all systemcalls looks like this.
> 
> cacheline              non-cacheline             Un-patched kernel 
> aligned patch 	       aligned patch                            
> ===============================================================================
> real    9m46.784s       9m54.412s                  10m2.450s   
> user    40m5.715s       40m7.142s                  40m4.273s 
> sys     2m57.754s       2m58.583s                  3m17.430s                            
> ===========================================================
> 
> Time duration for kernel compilation ("make -j 8) on the same system, when 
> kernel is not probed.
> =========================
> real    9m26.389s
> user    40m8.775s
> sys     2m7.283s
> =========================
> 
> Please let me know your comments on the patch attached here.
> 
> Signed-off-by: Srinivasa DS <srinivasa@in.ibm.com>
> Signed-off-by: Jim Keniston <jkenisto@us.ibm.com>

Acked-by: Ananth N Mavinakayanahalli <ananth@in.ibm.com>

  reply	other threads:[~2008-05-27  8:22 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-05-21  1:02 [RFC] [PATCH] To improve kretprobe scalability Srinivasa D S
2008-05-21 23:32 ` Andrew Morton
2008-05-22  8:26   ` Srinivasa D S
2008-05-27  8:22     ` Ananth N Mavinakayanahalli [this message]
2008-05-22  7:07 ` Abhishek Sagar
2008-05-22  8:42   ` Srinivasa DS
2008-05-22 12:16     ` Abhishek Sagar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20080527082242.GA3473@in.ibm.com \
    --to=ananth@in.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=jkenisto@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhiramat@redhat.com \
    --cc=srikar@linux.vnet.ibm.com \
    --cc=srinivasa@in.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.