All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@suse.de>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: andersen@codepoet.org, linux-kernel@vger.kernel.org
Subject: Re: Linux 2.4.18-pre9-ac1
Date: Tue, 12 Feb 2002 09:26:58 +0100	[thread overview]
Message-ID: <20020212092658.Z729@suse.de> (raw)
In-Reply-To: <20020212001547.GA22586@codepoet.org> <E16aQu1-00008C-00@the-village.bc.nu> <20020212092109.Y729@suse.de>
In-Reply-To: <20020212092109.Y729@suse.de>

On Tue, Feb 12 2002, Jens Axboe wrote:
> On Tue, Feb 12 2002, Alan Cox wrote:
> > > I notice that in linux/drivers/scsi/scsi_merge.c you seem to
> > > be reverting the MO drive clustering fix from Jens:
> > >     http://www.uwsg.indiana.edu/hypermail/linux/kernel/0202.0/1321.html
> > > 
> > > Was this intentional?  If so, why?
> > 
> > I want to find out why it was done first and then test it. Leaving it out
> > will ensure it bugs me until I test it
> 
> If you leave it out, you surely want to make sure that the other request
> init and re-init paths agree on the clustering for MO devices. Because
> they don't.
> 
> As far as I'm concerned, removing the MO conditional wrt clustering is
> the right fix.

BTW, if you are concerned with the write/read vs seek latencies of MO
drives, then the disable clustering hack was definitely the wrong way to
try and limit request sizes. In fact it achieved absolutely _nothing_.
Clustering at this level is completely device independent, too.

In short, the old code made no sense whatsoever.

Now, disabling request merging for MO devices might make a whole lot
more sense. That might be worth while trying, and I'd be happy to give
you a patch to try that out instead.

-- 
Jens Axboe


  reply	other threads:[~2002-02-12  8:27 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-02-11 23:01 Linux 2.4.18-pre9-ac1 Alan Cox
2002-02-12  0:15 ` Erik Andersen
2002-02-12  0:34   ` Alan Cox
2002-02-12  8:21     ` Jens Axboe
2002-02-12  8:26       ` Jens Axboe [this message]
2002-02-12 14:35         ` Alan Cox
2002-02-12 16:55           ` Jens Axboe
2002-02-12 18:40           ` Bill Davidsen
2002-02-12 20:05           ` Erik Andersen
2002-02-12  0:53 ` Pozsar Balazs
2002-02-12  1:00   ` Alan Cox
2002-02-12  4:46   ` Nick Orlov
2002-02-12 13:30 ` Pozsar Balazs
2002-02-12 15:13 ` Thomas Capricelli
2002-02-12 15:39   ` Alan Cox

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20020212092658.Z729@suse.de \
    --to=axboe@suse.de \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=andersen@codepoet.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.