| Either my comment was mistunderstood (e.g. we are each referring to different caches) or I am suffering from a fundamental misunderstanding. Let's say you have a diskless RAM-based system. Swapless. Now you launch a large program, say firefox or some other "modern web browser". That is going to require page caching, correct? This program cannot fit into the CPU cache, specifically what the Wikipedia entry (to use a common point of reference) calls the "data cache" (cf. what it calls the "instruction cache"). Now say you launch another large program. Depending on how much main memory you have, the OS is going to have to do some decision-making. Which program (or parts thereof) need to be "immediately available"? Now imagine you have a small program constructed from very dense code, say a few K in size, and it fits entirely within the data cache. Correct me if I'm wrong, but in that case there is no page caching or OS decision-making. The program is "immediately available" as long as it's in the data cache. OK, now I'm sure someone will take this comment apart piece by piece. But keep in mind the general idea I am suggesting is: code density lends itself to smaller programs, smaller programs lend themselves to fitting in the data cache, and fitting entirely within the CPU's data cache lends itself to running faster in a diskless RAM-based system. If this is wrong, then you need to explain why, specifically. |
Secondly, there is no signifcant address translation overhead and the os doesn't need to do any decision making (or well, it does, but it is cached in the TLB and code TLBs are so efficienct nowadays that you can expect the cost to be null) so long as the resident set fits in the main ram -- whether it fits in the cache or not is irrelevant.
Thirdly, just how does the disklessness of the system have any influence? I am not entirely sure but it seems you are somehow mixing up the page cache and the CPU cache, which are completely different things.