Return to BSD News archive
Newsgroups: comp.unix.bsd Path: sserve!manuel!munnari.oz.au!uunet!darwin.sura.net!jvnc.net!nuscc!ntuix!eoahmad From: eoahmad@ntuix.ntu.ac.sg (Othman Ahmad) Subject: Take out fs cache! Message-ID: <1992Jul9.141010.2324@ntuix.ntu.ac.sg> Organization: Nanyang Technological University - Singapore Date: Thu, 9 Jul 1992 14:10:10 GMT Lines: 76 Why was buffer cache introduced? Quoted from Bach,M.J.:The design of the Unix Operating System. i) uniform disk access for kernel, it does not have to know where. Rebuff: The complexity which may be less in the kernel code would have to be handled by other code. It is just inconceivable that we do not know where the data is to be fetched from or sent to. If you just examine the getblk(), it still has to calculate where in the cache the data has to come from. If there is no cache, everything would be even simpler. Less code. Just allow the user to access form device directly via the kernel. The user process sends the destination address, the kernel do block transfer from the device driver to the user-space directly without copying to the cache first. Would not the code be simpler because there is less work to do. ii)no data alignment restrictions: Rebuff: You can do the same without fs buffer cache. Just introduce device/driver cache. All hard-disks now have built in cache. iii)can reduce disk traffic: Only for randowm access. It becomes worse for sequential access. Large IO tasks are more frequently sequential and this is the most obvious performance limitation. Random accesses almost always transfer small amount of data. For large random access we may need index files which are best stored in RAM. Once the index is in RAM, the cache would reduce performance by half, unless the data is already there. Usually users need data only once, why should we penalise the whole system for infrequently used operation. For IO with cache there is 50% penalty for sequential access of large data, unless there is a mechanism to disable the cache.The reason is that data needs to be loaded to the cache first before being sent to the user. The penaly is minimal if the hard-disk is very slow but for RAMDISKS or disks with cache, this penalty rises to 50%. That means the fs cache let us down when we really need it. Also the penalty increases if the hard-disk is cached. iii) The buffer help ensure file system integrity by serialising access: If every transfer is controlled by the kernel, the integrity can still be maintained even without the cache. The cache is only feasible if hard-disks are not cached themselves or the hard-disk cache is much slower than system RAM. However even in these circumstances, the no fs cache is still faster, by having cache at the IO driver. Having specialised cache for a particular device is better than having a general purpose one. I bet that given the same amount of cache, the specialised IO cache would outperform an fs cache under similar conditions. Any data on this? I think the most valid reason for fs cache is the one described by A.S. Tanembaum in his book Design and Implementation of OS. In a microkernel, it would be better to modularise the design by letting the fs control the data transfer even at the expense of speed. The kernel is supposed to be a separate process. The above reasoning is similar to Bach (i). The solution would be to allow the kernel master control over all other processes although it has a separate state. It can manipulate the other process' memory space. After all, the kernel is the master. A bug in the kernel is a bug for all. This view is also good for hardware design. The kernel mode is equivalent to the real mode in X86 architecture. It is used for bootstrap before going into protected mode. The device drivers can be at separate processes. HOwever I do not know much about threads. For another angle of explanation please refer to my article at comp.unix.linux: Issues in Fs. -- Othman bin Ahmad, School of EEE, Nanyang Technological University, Singapore 2263. Internet Email: eoahmad@ntuix.ntu.ac.sg Bitnet Email: eoahmad@ntuvax.bitnet