On Wed, 24 Mar 1999, Eric Youngdale wrote:
> 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.
The plug seemed to me some helper for higher layers (which is basically
the kernel code). It is either candidate to stay here or to be removed
if it ever gets useless, indeed.
The current get_queue() stuff requires lower layers (Actual IO
sub-systems) to care of the plug if they want to do things right. This
spaghettied the IO layers in a evil way. That's the main reason I disagree
about the get_queue() stuff from the MAJOR+kdev_t in linux-2.2.
I never told that the plug/unplug thing was a bad thing in essence. Just
looking into how the kernel does IOs explains why it is here. The bad
thing had been to polluted actual IO-sub systems with such a concern
because of the get_queue() stuff, in my opinion.
> 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.
I understood all that since years, Eric. I never wrote that the
plug/unplug mechanism was currently a bad thing. If we want to get rid it,
we will have to do some heavy rework in upper layer, btw.
> 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.
The actual effect of the plug is needed due to how upper layers are
dealing with IOs. We can very probably find something more aesthetic than
the plug.
The pollution of IO-subsystems that have now to care of the plug if they
use the current multi-queue thing has been the real crap, IMO. As long
as the plug concern stays in ll_rw_blk, it will not appear to me as a
crap, but just as some trick that fixes some upper layer misbehaviour.
I didn't attack you in this thread, and I am sad that you may have thought
I did so. As you, I also haven't had time for improving the SCSI
sub-system and believe me, I wanted to do so.
> -Eric
Regards,
Gérard.
-
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/