From: Oleg Nesterov <oleg@redhat.com>
To: "Zhang, Yanmin" <yanmin_zhang@linux.intel.com>
Cc: Roland McGrath <roland@redhat.com>,
Andrew Morton <akpm@linux-foundation.org>,
LKML <linux-kernel@vger.kernel.org>,
andi.kleen@intel.com, stable@kernel.org
Subject: Re: [PATCH] Don't apply for write lock on tasklist_lock if parent doesn't ptrace other processes
Date: Mon, 26 Jul 2010 10:53:24 +0200 [thread overview]
Message-ID: <20100726085324.GA32223@redhat.com> (raw)
In-Reply-To: <1280120732.2085.3.camel@ymzhang.sh.intel.com>
On 07/26, Zhang, Yanmin wrote:
>
> On Fri, 2010-07-23 at 19:34 +0200, Oleg Nesterov wrote:
> > On 07/23, Zhang, Yanmin wrote:
> > >
> > > After applying my patch (although it's incorrect as there is a race with TRACEME),
> > > perf shows write_lock_irq in forget_original_parent consumes less than 40% cpu time on
> > > 8-socket machine.
> >
> > Any chance you can test the patch I sent? It should have the same effect,
> > otherwise there is something interesting.
> 1) with my patch, we got about 13% improvement;
> 2) With your patch, we got about 11% improvement;
>
> Performance is very sensitive to spinlock contention on large machines.
Zhang, thank you very much.
But. In this case I do not trust these results or I missed something.
I mean, they do not look 100% accurate.
With your patch:
forget_original_parent:
exit_ptrace:
if (list_empty(ptraced))
return;
write_lock_irq(tasklist);
... do a lot more work ...
With my patch:
forget_original_parent:
write_lock_irq(tasklist);
exit_ptrace:
if (list_empty(ptraced))
return;
... do a lot more work ...
The only difference is that we are doing the function call + list_empty()
under tasklist, just a few instructions compared to "do a lot more work"
in forget_original_parent().
How this can make the 2% difference ? This looks like a noise to me,
or do you think I missed something?
> > Heh. We must optimize it. But it is not clear when ;)
> Thanks. It's better to remove the big lock.
Yes. The only problem this is very much nontrival with the current code.
Oleg.
next prev parent reply other threads:[~2010-07-26 8:56 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-15 6:51 [PATCH] Don't apply for write lock on tasklist_lock if parent doesn't ptrace other processes Zhang, Yanmin
2010-07-15 19:53 ` David Rientjes
2010-07-21 21:49 ` Andrew Morton
2010-07-21 22:25 ` Roland McGrath
2010-07-22 9:05 ` Oleg Nesterov
2010-07-22 19:24 ` Roland McGrath
2010-07-23 17:40 ` Oleg Nesterov
2010-07-23 8:45 ` Zhang, Yanmin
2010-07-23 17:34 ` Oleg Nesterov
2010-07-26 5:05 ` Zhang, Yanmin
2010-07-26 8:53 ` Oleg Nesterov [this message]
2010-07-26 9:40 ` Kleen, Andi
2010-07-27 1:15 ` Zhang, Yanmin
2010-07-29 15:12 ` [PATCH] ptrace: optimize exit_ptrace() for the likely case Oleg Nesterov
2010-07-29 17:40 ` Roland McGrath
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=20100726085324.GA32223@redhat.com \
--to=oleg@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=andi.kleen@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=roland@redhat.com \
--cc=stable@kernel.org \
--cc=yanmin_zhang@linux.intel.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.