mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Al Boldi <a1426z@gawab.com>
To: "John Stoffel" <john@stoffel.org>
Cc: Jens Axboe <axboe@kernel.dk>, linux-kernel@vger.kernel.org
Subject: Re: What's in linux-2.6-block.git
Date: Wed, 13 Sep 2006 20:52:53 +0300	[thread overview]
Message-ID: <200609132052.53984.a1426z@gawab.com> (raw)
In-Reply-To: <17672.5209.158911.963437@smtp.charter.net>

John Stoffel wrote:
> >>>>> "Al" == Al Boldi <a1426z@gawab.com> writes:
>
> Al> Jens Axboe wrote:
> >> On Wed, Sep 13 2006, Al Boldi wrote:
> >> > Jens Axboe  wrote:
> >> > > This lists the main features of the 'block' branch, which is bound
> >> > > for Linus when 2.6.19 opens:
> >> > >
> >> > > - Splitting of request->flags into two parts:
> >> > >         - cmd type
> >> > >         - modified flags
> >> > >   Right now it's a bit of a mess, splitting this up invites a
> >> > > cleaner usage and also enables us to implement generic "messages"
> >> > > passed on the regular queue for the device.
> >> > >
> >> > > - Abstract out the request back merging and put it into the core io
> >> > >   scheduler layer. Cleans up all the io schedulers, and noop gets
> >> > >   merging for "free".
> >> > >
> >> > > - Abstract out the rbtree sorting. Gets rid of duplicated code in
> >> > >   as/cfq/deadline.
> >> > >
> >> > > - General shrinkage of the request structure.
> >> > >
> >> > > - Killing dynamic rq private structures in deadline/as/cfq. This
> >> > > should speed up the io path somewhat, as we avoid allocating
> >> > > several structures (struct request + scheduler private request) for
> >> > > each io request.
> >> > >
> >> > > - meta data io logging for blktrace.
> >> > >
> >> > > - CFQ improvements.
> >> > >
> >> > > - Make the block layer configurable through Kconfig (David
> >> > > Howells).
> >> > >
> >> > > - Lots of cleanups.
> >> >
> >> > Does it also address the strange "max_sectors_kb<>192 causes a
> >> > 50%-slowdown" problem?
> >>
> >> (remember to cc me/others when replying, I can easily miss lkml
> >> messages for several days otherwise).
> >>
> >> It does not, the investigation of that is still pending I'm afraid. The
> >> data is really puzzling, I'm inclined to think it's drive related. Are
> >> you reproducing it just one box/drive, or on several?
>
> Al> Several boxes, same drive.
>
> Al> /dev/hda:
>
> Al> ATA device, with non-removable media
> Al> 	Model Number:       WDC WD1200JB-00DUA0
> Al> 	Serial Number:      WD-WMACM1007651
> Al> 	Firmware Revision:  65.13G65
> Al> Standards:
> Al> 	Supported: 6 5 4 3
> Al> 	Likely used: 6
>
> I've got a pair of drives which are very close in model type, and I
> can run some non-destructive tests on them if you like to confirm
> what's going on here if you like:
>
>     /dev/hde:
>
>     ATA device, with non-removable media
> 	    Model Number:       WDC WD1200JB-00CRA1
> 	    Serial Number:      WD-WMA8C4365875
> 	    Firmware Revision:  17.07W17
>     Standards:
> 	    Supported: 5 4 3
> 	    Likely used: 6
>     jfsnew:~> sudo hdparm -I /dev/hdg | head
>
>     /dev/hdg:
>
>     ATA device, with non-removable media
> 	    Model Number:       WDC WD1200JB-00EVA0
> 	    Serial Number:      WD-WMAEK2844058
> 	    Firmware Revision:  15.05R15
>     Standards:
> 	    Supported: 6 5 4
> 	    Likely used: 6
>
> The drives have different defaul max_sectors too:
>     > cat /sys/block/hdg/queue/max_sectors_kb
>
>     512
>
>     > cat /sys/block/hde/queue/max_sectors_kb
>
>     128
>
> Let me know your test method and I'll run it here and post the
> results.

Thanks for your input!

Are you running UDMA5?  Can you dump the full hdparm -I

What thruput do you get with cat /dev/hd[eg] > /dev/null?

What does cat /sys/block/hde/queue/read_ahead_kb say?

Then try this for best performance:
echo 192 > /sys/block/hde/queue/max_sectors_kb
echo 192 > /sys/block/hde/queue/read_ahead_kb

and repeat the thruput test reporting vmstat results.


Thanks!

--
Al


  reply	other threads:[~2006-09-13 17:51 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-13 10:59 Al Boldi
2006-09-13 10:59 ` Jens Axboe
2006-09-13 11:35   ` Al Boldi
2006-09-13 11:56     ` Jens Axboe
2006-09-13 17:52       ` Al Boldi
2006-09-13 14:23     ` John Stoffel
2006-09-13 17:52       ` Al Boldi [this message]
2006-09-14 19:46         ` John Stoffel
  -- strict thread matches above, loose matches on Subject: below --
2006-09-12 10:11 Jens Axboe

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=200609132052.53984.a1426z@gawab.com \
    --to=a1426z@gawab.com \
    --cc=axboe@kernel.dk \
    --cc=john@stoffel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®