From: bob <bob@watson.ibm.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: bob <bob@watson.ibm.com>, Karim Yaghmour <karim@opersys.com>,
<okrieg@us.ibm.com>, <trz@us.ibm.com>,
linux-kernel <linux-kernel@vger.kernel.org>,
LTT-Dev <ltt-dev@shafik.org>,
Linus Torvalds <torvalds@transmeta.com>
Subject: Re: [ltt-dev] Re: [PATCH] LTT for 2.5.38 1/9: Core infrastructure
Date: Sun, 22 Sep 2002 19:03:01 -0400 (EDT) [thread overview]
Message-ID: <15758.19140.200081.346286@k42.watson.ibm.com> (raw)
In-Reply-To: <Pine.LNX.4.44.0209230101250.31981-100000@localhost.localdomain>
> > [...] On a technical note: a cache-line ping-ponging is bad - a global
> > spinlock is horrendous. They're different - the lock-less MP scheme gets
> > rid of them both.
>
> (on the contrary - a global spinlock is bad for exactly that reason,
> because it causes a cacheline ping-pong. So if two CPUs are trying to
> write trace events at once, you'll get the same effect as if they were
> using a global spinlock.)
>
> Ingo
Just want to be clear that we are going to a per-CPU buffer scheme.
However, for sake of argument, the above is still not true. A global lock
has a different (worse) performance problem then the lock-free atomic
operation even given a global queue. The difference is 1) the Linux global
lock is very expensive and interacts with potential other processes, and 2)
you have to hold the lock for the entire duration of logging the event;
with the atomic operation you are finished once you've reserved you space.
If you didn't use the expensive Linux global lock and just a global lock,
you could be interrupted in the middle of holding the lock and performance
would fall off the map.
-bob
Robert Wisniewski
The K42 MP OS Project
Advanced Operating Systems
Scalable Parallel Systems
IBM T.J. Watson Research Center
914-945-3181
http://www.research.ibm.com/K42/
bob@watson.ibm.com
next prev parent reply other threads:[~2002-09-22 22:58 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-09-22 5:43 Karim Yaghmour
2002-09-22 10:42 ` Ingo Molnar
2002-09-22 10:50 ` Ingo Molnar
2002-09-22 17:26 ` Roman Zippel
2002-09-22 18:35 ` Linus Torvalds
2002-09-22 19:18 ` Karim Yaghmour
2002-09-22 19:40 ` Ingo Molnar
2002-09-22 22:09 ` Karim Yaghmour
2002-09-22 22:24 ` Ingo Molnar
2002-09-22 22:41 ` Karim Yaghmour
2002-09-22 22:59 ` Ingo Molnar
2002-09-22 22:50 ` Ingo Molnar
2002-09-22 23:32 ` Karim Yaghmour
2002-09-23 7:41 ` Ingo Molnar
2002-09-23 15:12 ` Karim Yaghmour
2002-09-23 20:11 ` Andreas Ferber
2002-09-23 23:31 ` Karim Yaghmour
2002-09-22 21:29 ` [ltt-dev] " bob
2002-09-22 19:06 ` Karim Yaghmour
2002-09-22 19:33 ` Karim Yaghmour
2002-09-22 21:20 ` [ltt-dev] " bob
2002-09-22 21:39 ` Ingo Molnar
2002-09-22 22:37 ` bob
2002-09-22 22:55 ` Ingo Molnar
2002-09-22 22:52 ` bob
2002-09-22 23:02 ` Ingo Molnar
2002-09-22 23:03 ` bob [this message]
2002-09-22 23:19 ` Ingo Molnar
2002-09-22 23:50 ` bob
2002-09-22 23:32 ` Ingo Molnar
2002-09-23 0:07 ` bob
2002-09-23 7:27 ` Ingo Molnar
2002-09-23 13:59 ` bob
2002-09-23 0:08 ` Karim Yaghmour
2002-09-22 22:58 ` Karim Yaghmour
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=15758.19140.200081.346286@k42.watson.ibm.com \
--to=bob@watson.ibm.com \
--cc=karim@opersys.com \
--cc=linux-kernel@vger.kernel.org \
--cc=ltt-dev@shafik.org \
--cc=mingo@elte.hu \
--cc=okrieg@us.ibm.com \
--cc=torvalds@transmeta.com \
--cc=trz@us.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®