.> What benefit did you see from that, what was your reasoning behind the
.> change? Have you noted 16byte code alignment improvements with some processors?
I posted a message about that a while ago after noticing that some
interrupt handlers started in the last 4 bytes of a(n assumed) 16-byte
cacheline, and the first instruction in all of them was 5 bytes long.
According to the manuals the penalties for this can be huge, and there's
no way to mitigate them with branch prediction and prefetch. (How do you
predict an interrupt?) And even if you hit L1 with both fetches there is
a small penalty...
I couldn't find any way to test the patch, but there doesn't seem to be
any downside other than a lost 1K of memory on IOAPIC machines, and a possible
larger working set fighting for L1 space but that would require heavy
concurrent use of a very large number of interrupt vectors.
-------
Chuck
-
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/