OSDev.org

gaf wrote: Keeping the disk spinning is probably much more important than saving a couple of cpu cycles. As HDs are a million times slower than the processor it already takes long enough to get the data, so that you don't want to waste any time scheduling the request. By giving the disk driver a high priority you make sure that the I/O operations are distributed more equally, allowing the maximum band-width to be used.

I meant specificly for writes, not reads. I was really just looking for a low priority example, to counter my high priority example, and trying to wrap a disk cache into that.

As far as disk writes, though, I agree, you have to utilize the hardware appropriately, as it will always be a massive bottleneck. However, to give it priority over other tasks such as screen updates may not be desireable, imo (at least for a floppy driver). I wouldn't want to wait for a 800kb file to be written to a floppy before my mouse pointer would move.

Essentially, I'm just trying to avoid windows' form of disk multitasking, which appears to block the whole system while the disk is written to -- nasty!

--Jeff

I meant specificly for writes, not reads. I was really just looking for a low priority example, to counter my high priority example, and trying to wrap a disk cache into that.

Even with a disk cache the driver should - in my opinion - get called immediately. It can then either place the block in its buffer or schedule a disk write in case that the cache is already full.

If the driver has a low priority it might take ages until it gets called. By then many write request might have arrived, that of course can't all get scheduled at the same time. The result would be, that the disk is idle when the CPU has a high work-load, and busy when the CPU is halted. This also means that the user might have to wait ages for a program to load, although the CPU itself is currently idle. The delayed writes from a former peak in work-load would still occupy the disk, so that the executable couldn't be loaded.

How bad the problem really is also depends of course depends on the "permeability" of the priority system. The more low-priority tasks get to run while there're also active high-priority applications, the smaller the problem will eventually be.

What I could imagine is a low priority deamon that writes back dirty blocks from the cache when the system is idle..

I wouldn't want to wait for a 800kb file to be written to a floppy before my mouse pointer would move.

Using DMA the processor doesn't have to do any work while a disk writes/reads the data. The driver just tell the disk what must get transfered and then blocks until the request is completed. As disks are extremly slow compared to the procesor there's usually a lot of time in between the requests. Other applications can thus continue to run while being interrupted by the disk driver every now and then.

Essentially, I'm just trying to avoid windows' form of disk multitasking, which appears to block the whole system while the disk is written to -- nasty!

It's really amazing how much resources a device with a transfer rate of 288 Kbits can eat up if the system design is just bloated enough..

regards,
gaf

gaf wrote: Using DMA the processor doesn't have to do any work while a disk writes/reads the data. The driver just tell the disk what must get transfered and then blocks until the request is completed. As disks are extremly slow compared to the procesor there's usually a lot of time in between the requests. Other applications can thus continue to run while being interrupted by the disk driver every now and then.

I was under the impression that modern disk drivers (not floppy) no longer used DMA? Is this no longer true? Or perhaps you were talking about floppies.

I haven't written disk drivers yet, so I don't know a whole lot about them, but I thought methods such as PIO?, etc, were non-dma? I'm curious to get clarification on these things.

gaf wrote: It's really amazing how much resources a device with a transfer rate of 288 Kbits can eat up if the system design is just bloated enough..

True, indeed. I've been waiting for a complete rewrite for over a decade...

--Jeff

I was under the impression that modern disk drivers (not floppy) no longer used DMA? Is this no longer true? Or perhaps you were talking about floppies.

No, I was indeed talking about disks in general. You're right however that modern hardisks don't use the same DMA technique as their pre ATA-4 predecessors did until 1998. Back then the disk was still connected to the ISA bus and used the same ISA DMA controller as floppy and soundblaster. When PCI became the standard for hardisk controllers, the old DMA system was replaced with a completly new technique (UDMA 33/66/100/133) that also supported higher transfer-rates. Todays DMA doesn't use on a central chip to transfer data, but rather relies on the PCI capability of bus mastering. Using this technique a PCI device can get access to the system-memory without further assistance by the CPU. The hardisk can thus write/read whole chunks from a buffer in memory that has been assigned to it by the operating system.

For backwards compatibility PIO is still supported by all ATA/ATAPI devices. It should however only be used if there's no other possibility as the transfer-rate is limited to 16.7 MiB/s. Apart from that the processor utilization is much higher as all data has to be moved to/from the disk by the processor

You should find some more information in the pc guide and on the offcial site of the ATA/ATAPI standard committee.

regards,
gaf