Shared Memory

Lennart Sorensen lsorense-1wCw9BSqJbv44Nm34jS7GywD8/FfD2ys at public.gmane.org
Tue Feb 1 14:09:11 UTC 2005


On Tue, Feb 01, 2005 at 11:43:39AM +0200, Peter L. Peres wrote:
> I thought ncq was beneficial on scsi because several devices share the 
> bus. On sata there is only one per bus. How would they benefit from ncq 
> ?

No the idea is to issue multiple commands to each device in a queue and
letting the device schedule which order to serve them in based on where
it's head is and which order will get all the data the fastest.  Old
scsi disks might only have had an 8 command queue, while many newer
drives have 256 command queues.

This is very helpful if say two applications are both trying to read a
large file.  Both are issueing read requests but one is for blocks near
the start of the drive and the other is near the end.  If each got to
issue one command at a time, you would get requests for begining, end,
begining, end, begining, end, and your drive would have to seek back and
forth every command (and seek times are not THAT good even on new
drives), while if you had a 16 command queue, the drive would be able to
sort them and go 'read 8 blocks from the begining, then 8 blocks from
the end, then 8 blocks from the begining, etc', saving many ms of seek
times.  There has been some work on linux to implement command
reordering in the kernel to essentially emulate command queueing in
software and simply make sure to keep track of where the drive is.  Of
course the kernel doesn't know if the drive has remapped some bad
sectors to spares, and where those spares are, or how the drive is
physically layed out internally, so the drive really is better equiped
to know what order is optimal.  The kernel can help more by simply doing
read ahead by predicting what a program might want next in addition to
what it just asked for (so say program asks for on block, at a time, and
has done so for 50 blocks so far, maybe the kernel can ask the drive to
get it the next 10, so they are in the disk cache already when the
program asks for the next one).

Lennart Sorensen
--
The Toronto Linux Users Group.      Meetings: http://tlug.ss.org
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml





More information about the Legacy mailing list