phil@amdcad.UUCP (Phil Ngai) (01/18/87)
Several people have told me that although it is hard to simulate (one
person suggested using a logic analyzer to get address traces), it
does seem to be the case that the Unix kernel does not interact with
caches as well as applications such as nroff. This led me to wonder if
in that case, one might not do well to turn off the cache while the
processor is in supervisor mode, since the hit rate does not seem to
be very high and you thereby avoid flushing the cache of information
that is useful to the application. This assumes the kernel was entered
through a system call and returned to the same process. If a new
process was run, then 1) the cache would probably have to be much
larger and 2) process switches probably happen at a rate low enough
that it doesn't matter if the cache is invalidated. Anyway, these are
just guesses and I would like to invite discussion on this subject.
--
Warning: the California AAA is pursuing a policy which would spend
gasoline taxes on mass transit instead of roads.
Phil Ngai +1 408 749 5720
UUCP: {ucbvax,decwrl,hplabs,allegra}!amdcad!phil
ARPA: amdcad!phil@decwrl.dec.commash@winchester.UUCP (John Mashey) (01/18/87)
In article <14362@amdcad.UUCP> phil@amdcad.UUCP (Phil Ngai) writes: >...does seem to be the case that the Unix kernel does not interact with >caches as well as applications such as nroff. This led me to wonder if >in that case, one might not do well to turn off the cache while the >processor is in supervisor mode, since the hit rate does not seem to >be very high and you thereby avoid flushing the cache of information >that is useful to the application.... 1) There ARE places in teh kernel that are worth selective uncaching. 2) In general, uncaching the kernel is probably not the thing to do, although this may vary according to cache design, applications, etc. In particular, as caches continue to increase in size, kernel cache residence in a multi-process environment incerases substantially. Some modest evidence: a) There's been some interesting recent research on the area at Stanford. b) We've experimented a lot at MIPS, especially early, with uncached kernels; we also changed I-cache sizes at one point. The results [I can't give you the details] : our kernels run cached. -- -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!mash, DDD: 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086
johnl@ima.UUCP (John R. Levine) (01/19/87)
In article <14362@amdcad.UUCP> phil@amdcad.UUCP (Phil Ngai) writes: >Several people have told me that ... it >does seem to be the case that the Unix kernel does not interact with >caches as well as applications such as nroff. This led me to wonder if >in that case, one might not do well to turn off the cache while the >processor is in supervisor mode ... That's probably not such a great idea. Even kernel code contains loops, and I'd expect there to be a huge performance loss if kernel code wasn't cached. Perhaps you'd be better off leaving instruction cacheing on but turning data cacheing off. Or maybe have a separate small I cache for the kernel, so that when you return to the user, in the presumably common case that the user program will continue doing what it did before, its caches are still set up. By the way, has anybody looked at the relative cost of reloading the memory cache vs. reloading the address translation cache across system calls or process switches? -- John R. Levine, Javelin Software Corp., Cambridge MA +1 617 494 1400 { ihnp4 | decvax | cbosgd | harvard | yale }!ima!johnl, Levine@YALE.something Where is Richard Nixon now that we need him?