From: Arjan van de Ven <arjan@infradead.org>
To: John Richard Moser <nigelenki@comcast.net>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Can context switches be faster?
Date: Thu, 12 Oct 2006 21:02:45 +0200 [thread overview]
Message-ID: <1160679765.3000.468.camel@laptopd505.fenrus.org> (raw)
In-Reply-To: <452E8FE1.7080503@comcast.net>
On Thu, 2006-10-12 at 14:56 -0400, John Richard Moser wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>
> Arjan van de Ven wrote:
> > On Thu, 2006-10-12 at 14:25 -0400, John Richard Moser wrote:
> >
> > Hi,
> >
> >> So apparently most CPUs virtually address L1 cache and physically
> >> address L2; but sometimes physically addressing L1 is better.. hur.
> >
> > if you are interested in this I would strongly urge you to read Curt
> > Schimmel's book (UNIX(R) Systems for Modern Architectures: Symmetric
> > Multiprocessing and Caching for Kernel Programmers); it explains this
> > and related materials really really well.
> >
>
> That will likely be more useful when I've got more background knowledge;
the book is quite explenatory, so maybe your uni has it in the library
so that you can try to see if it makes sense?
> >
> > the cache flushing is a per architecture property. On x86, the cache
> > flushing isn't needed; but a TLB flush is. Depending on your hardware
> > that can be expensive as well.
> >
>
> Mm. TLB flush is expensive, and pretty unavoidable unless you do stupid
> things like map libc into the same address everywhere.
TLB flush is needed if ANY part of the address space is pointing at
different pages. Since that is always the case for different processes,
where exactly glibc is doesn't matter... as long as there is ONE page of
memory different you have to flush. (And the flush is not expensive
enough to do partial ones based on lots of smarts; the smarts will be
more expensive than just doing a full flush)
> TLB flush
> between threads in the same process is probably avoidable; aren't
> threads basically processes with the same PID in something called a
> thread group? (Hmm... creative scheduling possibilities...)
the scheduler is smart enough to avoid the flush then afaik
(threads share the "mm" in Linux, and "different mm" is used as trigger
for the flush. Linux is even smarter; kernel threads don't have any mm
at all so those count as wildcards in this respect, so that if you have
"thread A" -> "kernel thread" -> "thread B" you'll have no flush)
next prev parent reply other threads:[~2006-10-12 19:02 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-12 15:44 John Richard Moser
2006-10-12 15:53 ` John Richard Moser
2006-10-12 17:19 ` Russell King
2006-10-12 18:25 ` John Richard Moser
2006-10-12 18:37 ` Arjan van de Ven
2006-10-12 18:56 ` John Richard Moser
2006-10-12 19:02 ` Arjan van de Ven [this message]
2006-10-13 11:05 ` James Courtier-Dutton
2006-10-13 14:51 ` Chase Venters
2006-10-12 18:20 ` Phillip Susi
2006-10-12 18:29 ` John Richard Moser
2006-10-13 2:53 ` Andrew James Wade
2006-10-13 5:29 ` John Richard Moser
2006-10-13 16:56 ` Andrew James Wade
2006-10-13 17:24 ` John Richard Moser
2006-10-12 19:57 ` Chris Friesen
2006-10-12 20:23 ` John Richard Moser
2006-10-12 20:29 ` Arjan van de Ven
2006-10-12 20:36 ` John Richard Moser
2006-10-12 20:35 ` Jeremy Fitzhardinge
2006-10-13 23:32 ` Andreas Mohr
2006-10-13 23:47 ` David Lang
2006-10-14 0:14 ` Jeremy Fitzhardinge
2006-10-14 0:30 ` Alan Cox
2006-10-14 0:14 ` Jeremy Fitzhardinge
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=1160679765.3000.468.camel@laptopd505.fenrus.org \
--to=arjan@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nigelenki@comcast.net \
/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®