From: unixsys@ssg.com (Rick Emerson) Subject: Re: [comp.os.linux]: Re: Take out fs cache! Date: Tue, 14 Jul 1992 11:40:37 GMT
news-daemon@optical.bms.com writes:
> Newsgroups: comp.os.linux
> Path: synapse.bms.com!jvnc.net!yale.edu!yale!mintaka.lcs.mit.edu!bloom-picayu
> From: arybicki.lax1b@xerox.com
> Subject: Re: Take out fs cache!
> Message-ID: <1992Jul9.170507.18315@athena.mit.edu>
> Sender: daemon@athena.mit.edu (Mr Background)
> Reply-To: arybicki.lax1b@xerox.com
> Organization: The Internet
> Date: Thu, 9 Jul 1992 17:05:07 GMT
> Lines: 59
>
> In article <1992Jul9.141201.2404@ntuix.ntu.ac.sg> Othman Ahmad writes:
>
> |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.
>
> Not all the hard disks have built in cache--only the newer and more
> expensive ones. And if they do, the cache is usually: A) small (64K-256K)
> B) unaware of how the FS accesses the data.
Bingo! I'm hard pressed to accept the idea of buying a new disk drive just
so write-back can be eliminated. This strikes me as an excellent example of
throwing the baby out with the bath water.
> |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.
>
> That could have been true for single-tasking MS-DOG, but with multiple tasks
> trying to get at their data as far as the FS is concerned, these are still
> random accesses.
I fail to see the tariff of accessing sequential sections through caching.
If anything, there might still be a very slight improvement only because
head action is limited but that's strictly a guess. The cache, of course,
is intened to cover up the cost of random access. This seems like a win/win
situation to me.
> |...
> | 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%.
>
> Where did this 50% 'magic number' come from? From my experience IN REAL
> LIFE APPLICATIONS FS has never degraded the system's performance with the
> exception of running disk benchmarking programs. Also, the overhead of
> reading into RAM and then to the requesting program can never be all that
> big. With today's technology data cannot be read physically from the disk
> faster than about 1.5 MB/sec. I'll let you guess how many times faster it
> can be transfered from a cache (hint: depends on your PC's speed.)
Agreed. I'd like to see the justification for that 50% number. Part of my
work is with capturing weather satellite imagery. I routinely write 4.5MB
contiguous *sequential* files in real time and a 50% penalty would kill the
process. Instead, the process capture the files, through a write-back
cache; prima face demonstration that the penalty either doesn't exist or is
magnitudes of order less than 50% (of what???).
> |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?
>
> Yes, think about this: Your HD has this cache memory. To transfer this to
> system RAM it sends it to the controller which sits where? AT BUS!!! And
> even if it's EISA, it cannot outperform the RAM-to-RAM transfer of cacheing
> FS.
Agreed.
Rick
+--------------------------------------------------------------------------+
| Richard B. Emerson | Replies may be sent to: |
| System Support Group | rick@ssg.com |
| Post Office Box 180 |-------------------------------------------------+
| Lansdale, PA 19446 USA | "Answers are the easy part |
| Voice: 215.855.1607 | questions raise the doubt." - Jimmy Buffett |
+--------------------------------------------------------------------------+