Subject: Re: multi-core router
To: Erik Fair <fair@netbsd.org>
From: Thomas E. Spanjaard <tgen@netphreax.net>
List: tech-kern
Date: 11/04/2007 17:10:46
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigC0F93E9FECB54ABBD8311697
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Erik Fair wrote:
> Actually, that's similar to what Matt Dillon has been doing in  
> DragonFly BSD - dedicating particular kernel threads to particular  
> processors. He and I had a long discussion about it a few years ago.  I 
> haven't been paying close attention to what he's been doing since,  but 
> he claimed that the approach worked well (as opposed to  generalized SMP 
> where any processor is elegible to run processes/ threads) because it 
> resulted in much better cache utilization. I was  worried about one core 
> (or CPU) being overburndened while the other (s) idled, but he claimed 
> that was not a problem in practice.

He might have plans to do that, but that's not the current reality in 
DragonFly; at least, not to the point of dedicating a core to certain 
jobs like transput, and NOT using it for anything else. What is true 
though is that each core basically manages itself, in that it runs its 
own scheduler, manages its own routing table, etc. Also, threads 
basically belong to a single core, and usually don't get shuffled around 
if they allow so. This also amounts to better cache utilization and less 
TLB purge/refill activity.

On a sidenote, it might be beneficial to take advantage of shared caches 
in e.g. Core 2 family CPUs, where a number of cores (in current models, 
2) share a common L2 or L3 cache, which makes sharing threads between 
them a bit less of a problem regarding cache utilization. As far as I 
know, no current open-source operating system makes decisions on a level 
like this, with this kind of knowledge about the hierarchy of the system.

Cheers,
-- 
         Thomas E. Spanjaard
         tgen@netphreax.net

--------------enigC0F93E9FECB54ABBD8311697
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (NetBSD)

iD8DBQFHLf0a6xCMwBJ+1+sRA008AJ9Yv9U3Ey2hYtdFqEPtP3sWNfrA8QCfa8py
eA/BSLGGtgwlkrke0Yr6cFg=
=zzUx
-----END PGP SIGNATURE-----

--------------enigC0F93E9FECB54ABBD8311697--