Thank you for your response, Robert. Another question that I have is regarding my second experiment. It's as follows: Create a bio structure in my driver and call the __make_request() function of the lower level driver. Only one 2560 bytes write request is sent from my driver. Once this write is serviced, an interrupt is generated which is intercepted by do_IRQ(). Finally, the function blk_complete_request() is called. Keep in mind that we are still in the top half of the interrupt handler. Now, we compose another struct bio in blk_complete_request() and call the __make_request() function. We record a timestamp at this point (say T0). When the request completion callback is obtained, we record another timestamp (call it T1). The difference - T1 - T0 - is always above 1 millisec. This experiment was repeated numerous times, and each time, the destination sector affected this difference - T1 - T0. It was observed that if the destination sectors are separated by approximately 350 sectors, the time difference is about 1.2 millisec (never below 1 millisec) for requests of size 2560 bytes. My understanding is that since the destination sectors of consecutive requests have been separated by a fairly large amount, by the time the next request is issued, the requested sector would be almost below the disk head and thus the write should happen immediately and T1 - T0 should be small (at least < 1 millisec). The Serial ATA AHCI 1.3 Specification (page 114) states that: When a software specified number of commands have completed or **a software specified timeout has expired, an interrupt is generated by hardware to allow software to process completed commands.** I assumed that this timer maybe the reason why the latency of each request is above 1 millisec; that's why I wanted to disable CCC. Now since CCC is out of the picture, what could be the reason why the latency is above 1 millisec always? Can we do better? Regards, Pallav On Mon, May 23, 2011 at 4:27 PM, Robert Hancock <hancockrwd@xxxxxxxxx> wrote: > On Mon, May 23, 2011 at 8:36 AM, Pallav Bose <pallavbose@xxxxxxxxx> wrote: >> Hello Robert, Sergei, >> >> Thank your for your replies. >> >> On Thu, May 19, 2011 at 10:14 PM, Robert Hancock <hancockrwd@xxxxxxxxx> wrote: >>> >>> I suspect that there is something going on that you're not accounting for. Are you sure that you're not getting multiple outstanding writes in parallel somehow? Although the controller won't batch completions, the drive is free to do so if there are multiple queued commands outstanding at once (it can send a Set Device Bits FIS with multiple bits set). >> >> I don't believe this is the case because a write request is sent only >> _after_ the previous write request's response is received. >> >> You mentioned that the drive is free to batch completions if there are >> multiple queued commands outstanding at the same time. Is there a way >> to disable this feature? If my understanding is correct, since CCC is >> out of the picture, the drive is the only one that could be batching >> the responses? Or are there other possible candidates?! > > I don't think there's any way to disable it in the drive, the firmware > either decides to do that or it doesn't. Of course if the commands are > truly being serialized then this shouldn't be able to happen either. > >> >> On Fri, May 20, 2011 at 6:49 AM, Sergei Shtylyov <sshtylyov@xxxxxxxxxx> wrote: >>> I don't understand. This controller is not AHCI, and not even SATA one. >> >> Sorry about that. I should have been more careful when pasting the >> output of lspci. Here is the SATA controller: >> >> RAID bus controller: Intel Corporation 82801 SATA RAID Controller (rev 02) >> >> Regards, >> Pallav >> > -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
