lkml.org 
[lkml]   [1999]   [Mar]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:51    [W:0.120 / U:0.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site