mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Steve Lord <lord@sgi.com>
To: Jens Axboe <axboe@suse.de>
Cc: Linux Kernel <linux-kernel@vger.kernel.org>
Subject: SCSI I/O performance problems when CONFIG_HIGHIO is off
Date: 15 Nov 2002 14:31:51 -0600	[thread overview]
Message-ID: <1037392310.13531.419.camel@jen.americas.sgi.com> (raw)

Jens,

As you know, for the last week or so I have been battling some
performance issues in XFS and 2.4.20-rc1. Well, we finally found
the culprit back in 2.4.20-pre2.

When the block highmem patch was included, it added highmem_io to the
scsi controller structure. This can only ever be set to one if
CONFIG_HIGHIO is set. Yet there are several spots in the scsi
code which test based on its value regardless.

        /*
         * we really want to use sg even for a single segment request,
         * however some people just cannot be bothered to write decent
         * driver code so we can't risk to break somebody making the
         * assumption that sg requests will always contain at least 2
         * segments. if the driver is 32-bit dma safe, then use sg for
         * 1 entry anyways. if not, don't rely on the driver handling this
         * case.
         */
        if (count == 1 && !SCpnt->host->highmem_io) {
                this_count = req->current_nr_sectors;
                goto single_segment;
        }

Running with 128M of memory I usually do not turn highmem on. Well
finally I did and my performance went from this:

Version 1.02a       ------Sequential Create------ --------Random Create--------
burst.americas.sgi. -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                  2   156   4 +++++ +++   118   3   149   3 +++++ +++   108   2

which is the worst I ever saw, to this:

Version 1.02a       ------Sequential Create------ --------Random Create--------
burst.americas.sgi. -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                  2  2732  81 +++++ +++  1771  38  2555  86 +++++ +++  1418  30

Jens, can you do something about this please?

Steve

p.s. You now owe me a week's consulting some time ;-)


-- 

Steve Lord                                      voice: +1-651-683-3511
Principal Engineer, Filesystem Software         email: lord@sgi.com

             reply	other threads:[~2002-11-15 20:25 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-11-15 20:31 Steve Lord [this message]
2002-11-16  8:18 ` Jens Axboe
2002-11-18 12:05 ` Jens Axboe
2002-11-18 14:05   ` Stephen Lord
2002-11-18 14:12     ` 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=1037392310.13531.419.camel@jen.americas.sgi.com \
    --to=lord@sgi.com \
    --cc=axboe@suse.de \
    --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®