I used to be a sw fill proponent, but I've grown personally convinced that
while sw fill is good, it needs a few things:
- large on-chip TLB to avoid excessive trashing (ie preferably thousands
of entries)
This implies that the TLB should be split into a L1 and a L2, for all
the same reasons you split other caches that way (and with the L1
probably being duplicated among all memory units)
- ability to fill multiple entries in one go to offset the cost of taking
the trap.
Without that kind of support, the flexibility advantages of a sw fill just
isn't enough to offset the advantage you can get from doing it in
hardware (mainly the ability to not have to break your pipeline).
An in-memory hash table can of course be that L2, but I have this strong
suspicion that a forward-looking chip engineer would just have put the L2
on the die and made it architecturally invisible (so that moore's law can
trivially make it bigger in years to come).
Linus
-
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/