If another CPU then tries to reread that data, it is
provided directly in a cache to cache transfer and becomes
The data eventually is written back to main memory only when that
cache block is needed to hold different data by a read. In this case,
the read operation is held in an input buffer, while the dirty cache
block is copied to an output buffer. The read from memory then
completes, and finally the dirty cache line write completes.
Another situation to consider is the case of a context switch or a
process exiting. If an address space is no longer valid, the cache tags
might also be invalid. For systems that store a virtual address in the
cache tag, all the invalid addresses must be purged; for systems that
only store a physical address in the cache tag, there is no need.
Older SPARC systems, the HyperSPARC range, and some other systems
such as HP-PA use virtual caches. SuperSPARC and UltraSPARC use
physical caches. To be very general, a virtual cache can be faster for
uniprocessor systems and scientific workloads, and a physical cache
scales much better on multiprocessor systems and commercial workloads
that have numerous context switches. There are a lot more ways to
implement caches. If you are interested I recommend you read
Computer Architecture: A Quantitative Approach, by John
Hennessy and David Patterson.
Returning to the DNLC, when a file is created or deleted the new
directory entry is written to disk or sent over NFS immediately, so it
is a slow operation. The extra overhead of updating or purging the DNLC
is very small in comparison. The name service cache does not get
involved in updates. If someone changes data in the name service, the
nscd relies on timeouts and watching the modification
dates on files to register the change.
When does a cache work well? A cache works well if there are a lot
more reads than writes, and the reads or writes of the same or nearby
data occur close together in time. An efficient cache has a low
reference rate (doesn't make unnecessary lookups), a very short cache
hit time, a high hit ratio, the minimum possible cache miss time, and
an efficient way of handling writes and purges -- some tradeoffs may be
made. A small fast cache might have a lower hit ratio, but compensate
by having a low miss cost. A big slower cache can compensate for the
extra miss cost by missing much less often.
Beware of looking at hit ratio's alone. A system might be running
more efficiently by referencing the cache less often. If there are
multiple levels of cache, and the first level is working well, the
second level will tend to see a higher proportion of misses, but a low