Return to BSD News archive
Newsgroups: comp.os.386bsd.development
Path: sserve!manuel.anu.edu.au!munnari.oz.au!news.Hawaii.Edu!ames!agate!howland.reston.ans.net!wupost!csus.edu!netcom.com!jmonroy
From: jmonroy@netcom.com (Jesus Monroy Jr)
Subject: Re: Caching controllers
Message-ID: <1993Mar3.092409.20185@netcom.com>
Organization: Netcom - Online Communication Services (408 241-9760 guest)
X-Newsreader: TIN [version 1.1 PL6]
References: <18731@umd5.umd.edu>
Date: Wed, 3 Mar 1993 09:24:09 GMT
Lines: 157
mail mark@roissy.umd.edu
Re: Subject: Re: Subject: Re: Caching controllers
>> > In the case of the MS-DOS type controllers the cache software
>> > expects to find the information at a specific place on the HD,
>> > ::
>>
>> So you are supposing that the disk controller knows what a DOS
>> filesystem looks like, and is doing read-aheads based on that?
>>
I am not supposing the cache software is.
>> > ::
>> > What I said is all kinda circular.. so if it does not make sense,
>> > ASK me again!
>>
>> Yeah, let's try that. Here is what I expect to happen:
>>
>> reading:
>>
>> - any block that Unix kept in the buffer cache doesn't matter, because
>> it never gets to the controller
>>
Correct.
>> - any block that the disk controller kept in the cache, but which we
>> didn't want should _not_ slow us down. in this condition, the
>> cache should behave just like a non-caching controller. (this is what
>> I expect for what you described above.)
>>
No since we wanted a block that the cache does not have it will
1. search the cache
2. "take a miss" on the cache
3. start the search for the block we want
4. do the read
5. do the read-ahead
6. give us our block
>> - any block that we want (that the controller kept in the cache) will
>> be speeded up, though we might not benefit as much as we would on DOS
>> because the controller will be caching the wrong blocks
>>
In this area it is hard to say what the results would be but
definitely, if the controller is setup for MS-DOS there is
a very high likelihood that a hit will not occur.
>> writing:
>>
>> - any form of write-behind should benefit us. if it doesn't do write-behind,
>> it should be just like a non-caching controller.
>>
Yes, except that with a write behind it will do another read-ahead.
>> >>> Do you have any hard data
>> >>> on this? (e.g. response times of various controllers with the same disks?)
>> >>>
>> > Visual evidence, seeing it run on other peoples's systems.
>> > The experiment involved moving one jumper.
>>
>> Was that jumper to enable/disable the caching?
>>
Yes, sorry not to be clear about that.
>> I've been thinking of a few things that a "smart" controller might do that
>> would slow down non-dos systems:
>>
>> - It might do automatic seeks, trying to keep the disk head near the FAT.
YES!! definitely.
>> This would have the effect of constantly moving the disk head _away_
>> from where we want it.
>>
YES, again.
>> - It might do read-aheads poorly. e.g. If it is doing a read-ahead, and
>> the CPU requests disk i/o, the controller may complete it's read-ahead
>> before servicing the CPU request.
>>
Even at this point, it get very theoretical
>> This would slow things down by
>> something on the order of 1 / ( revolutions_per_sec * sectors_per_track).
>>
Still depends mostly on the controller software.
>> > The key point is that the hardware is duplicate what the software
>> > does and in any environment this is always a performance lose.
>>
>> You only lose from the theoretical performance you could get out of the
>> system. If the hardware does disk caching, the only loss is (the time
>> the software spends doing it's own caching) - (the time it takes to fetch
>> something from the hardware cache). The Unix buffer cache is pretty
>> fast about finding things.
>>
The miss is the problem.... On a MS-DOS type controller it
will research a nonexistent FAT.
On the read-ahead-type, it does not know which block is next,
hence here is the picture:
WE want blocks 15,249,510 & 252 (request #1)
110, 112, 152 (request #2)
DL +-----------------------------------------------------------+
IA |001|002|...|...|...|...|078| | | | | | | |249|
SY |250|251|252| | | | | | | | | | | |449|
KO |500|...|...|...|510|...| | | | | | | | | |
U | | | | | | | | | | | | | | | |
T | | | | | | | | | | | | | | | |
+-----------------------------------------------------------+
In this picture it will read a whole row (001-249).
So block 15 & 249 are gotten from the *NIX cache.
501 is next, but software will request 252 then 501.. it is smart.
The hardware cache gets 252, reads-ahead to 449 *or 502* if even
smarter (so to speak).
Now you get 252 back.
You request 510.
The hardware looks, takes a miss, gets 510, you get 510.
^^^^^Some loss not too bad though^^^^^
(second request comes in)
The software cache knows where it left off, so it will request in
this order.... 152, 112 ,110
At this point the Hardware cache will take a miss every time,
Because it is doing a read-ahead (in a forward direction).
I Hope this is clear.
>> I think it is more likely that the "smart" disk controller is doing more
>> than just caching, and in that way, actively working against us.
>>
>>
>> So did I get your point?
>>
Yes, but I am sending this to help illustrate my point more.
There are some controllers that work actively with the OS
such as those with drivers designed for
SCO (Santa Cruz Operations) Xenix & Unix they have a mechanism
for flushing the cache when needed.
-----------------------
BTW,
cache - a hiding place for provisions and treasures
-Oxford American Dictionary