linux-kernel - Re: Can context switches be faster?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1160679765.3000.468.camel@laptopd505.fenrus.org>
Date:	Thu, 12 Oct 2006 21:02:45 +0200
From:	Arjan van de Ven <arjan@...radead.org>
To:	John Richard Moser <nigelenki@...cast.net>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: Can context switches be faster?

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)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/