Messages in this thread | | | Date | Wed, 24 Mar 1999 21:44:31 -0500 (EST) | From | Eric Youngdale <> | Subject | Re: disk head scheduling |
| |
On Wed, 24 Mar 1999, Gadi Oxman wrote:
> On Wed, 24 Mar 1999, Gerard Roudier wrote: > > > You only thought IDE and it what I pointed out, btw. > > For SCSI with 1 queue per device, if we are globally plugged we lose > > time (think of SMP, and interruptions), and if we discard the plug, we > > may break the coalescencing and sorting, and then just provide devices > > with bunches small IOs. > > I admit that not implementing per-queue plugs at that time was a mistake. > The time in which the plug is being held should be very short relative to > actual I/O times, though, just enough to let the higher layers complete > putting all those small requests and colaescencing them, which is a > CPU <--> memory operation.
Look - the plug was a huge mistake. I should know - I am the one responsible for it. I always intended to go back and get rid of the thing and do it better, and I never got around to it.
It wasn't added arbitrarily - it was added to solve a specific problem. Let's say for example that you are repeatedly making requests of 16 blocks - without the plug the 1st block would get queued, and then the remaining 15 would be combined into 1 request. You would then get a pattern of reads of 1, 15, 1, 15, 1, 15 blocks. Roughly a 50% degradation.
What I *SHOULD* have done is something different. Two possibilities come to mind - there may well be others that are better. One possibility is to move the call to the queueing function up one level. A couple of wins here - you don't have the overhead of queueing for each and every block when you know that more will be coming along as soon as you are done processing them. The other possibility would be that you string the buffers together ahead of time (before you allocate a request) and then create and insert the request in one atomic operation. Either one works without all of that plug crap. There is no reason we cannot eliminate the thing entirely.
-Eric
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |