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>
next prev parent 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.