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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/