Messages in this thread | | | Date | Wed, 15 May 2002 12:55:37 +0100 | From | Neil Conway <> | Subject | Re: [PATCH] 2.5.15 IDE 61 |
| |
Denis Vlasenko wrote: > > On 15 May 2002 07:32, Martin Dalecki wrote: > > >> Yes thinking about it longer and longer I tend to the same conclusion, > > >> that we just shouldn't have per device queue but per channel queues > > >> instead. > > IMHO logically request queue is a separate entity for each disk. > IDE can have 2 devices on one cable (or more: think about > buggy cmd640 like chipset as a weird IDE with four disks > on a channel since we can talk to one disk only at a time).
Actually, since Martin pointed out the hardsect stuff, I'm inclined to think per-device queues but with a per-channel busy flag are the best idea. Or perhaps I should call it a per-channel "Don't touch the cable" flag. See below.
> It is a _spin_ lock. > Does this mean you will spin on it while IDE request for other disk > is processed?
No. An SMP machine will spin on it only while the queue-handling code is active. During the pause while the disk fetches the sectors from the media, no problem.
> Somebody enlighten me: can IDE mix reqests and completion like this:
I'll try (!) Treat my words with caution ;-)
> host ----read reqest---> master > host ----read reqest---> slave (is this possible?)
No, in general. Not unless you're using tagged command queueing. This is because the master won't have performed a bus-release on any normal R/W command. Once you are using TCQ it's OK though (tricky but OK).
You can (and must) safely "touch the cable" in between TCQ commands in the right circumstances. You are therefore touching the cable while the hwgroup is busy, hence my suggestion that the flag we use to prevent touching the cable during DMA should be named something other than busy.
Neil - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |