Path: utzoo!utgpu!water!watmath!clyde!bellcore!rutgers!rochester!cornell!uw-beaver!tektronix!uunet!munnari!basser!steve
From: steve@basser.oz (Stephen Russell)
Newsgroups: comp.arch
Subject: Costs of physical vs virtual caches
Message-ID: <1331@basser.oz>
Date: 23 Jul 88 01:22:11 GMT
References: <60952@sun.uucp>
Reply-To: steve@basser.oz (Stephen Russell)
Organization: Dept of Comp Sci, Uni of Sydney, Australia
Lines: 22

In article <60952@sun.uucp> dre%ember@Sun.COM (David Emberson) writes:

>With virtual caches, VM does not cause a performance penalty worth mentioning.

Only for compute-bound applications, which have minimal interaction with the OS.
Most virtual caches are not well designed, and often require flushing on
entry and exit to the OS. Worse, the sorts of tricks that an OS performs
with address manipulation may generate aliases that confuse the virtual
cache. Also, virtual caches find it difficult to 'snoop' the bus to ensure
data consistency after external sources, like i/o devices and other processors,
have fiddled with memory. Again, this can be a real problem for an OS, although
it only affects the D cache (usually). In general, virtual caches are a pain in
the neck for OS implementors.

>Even on some machines with physical caches, address translation can take place
>in parallel with the cache tag access--thus no penalty.
>			Dave Emberson (dre@sun.com)

This is the real point: physical caches avoid the problems above, and can be
built to have NO (or acceptably small) speed penalty. So, they don't impact
CPU intensive jobs, but win big for highly interactive or real time systems
where OS overhead costs are significant.