Staring at too many horrific profile outputs does that to one.
These are *the* two big locks.
> You pushed the performance degradation
> from the PIV to the PIII (because it will tend to hit more cachelines than it
> should)
The buddy info is all in one cacheline and the LRU info is in another.
So there's no loss to PIII here. But those two things are soooo hot
that paranoia is warranted.
> and you won't be able to build a kernel that is optimal for the PIII
> any more. I'd say that is PIII kernel is *supposed* to suck to some degree
> when run on a PIV, otherwise why bother having the PIV option?
>
> I expect the performance difference you're talking about is marginal anyway.
> Maybe you've measured it?
No, I haven't. NUMA boxes don't need it if the node-local allocation is
working right. But if they go cross-node much, it'll help. On high-performance
UMA SMP, allowing those two particular locks to fall into the same cacheline
is a big goofup.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/