Post by Erik FairActually, 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
***@netphreax.net