linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andi Kleen <ak@muc.de>
To: Steve Lord <lord@xfs.org>
Cc: Marcelo Tosatti <marcelo.tosatti@cyclades.com>,
	Mel Gorman <mel@csn.ul.ie>,
	William Lee Irwin III <wli@holomorphy.com>,
	Linux Memory Management List <linux-mm@kvack.org>,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	Grant Grundler <grundler@parisc-linux.org>
Subject: Re: [PATCH] Avoiding fragmentation through different allocator
Date: Tue, 25 Jan 2005 08:39:31 +0100	[thread overview]
Message-ID: <m1mzuyt0ss.fsf@muc.de> (raw)
In-Reply-To: <41F55EE1.5090702@xfs.org> (Steve Lord's message of "Mon, 24 Jan 2005 14:47:29 -0600")

Steve Lord <lord@xfs.org> writes:
>
> I realize this is one data point on one end of the scale, but I
> just wanted to make the point that there are cases where it
> does matter. Hopefully William's little change from last
> year has helped out a lot.

There are more datapoints: 

e.g. performance on megaraid controllers (very popular because a big
PC vendor ships them) was always quite bad on Linux. Up to the point
that specific IO workloads run half as fast on a megaraid compared to
other controllers. I heard they do work better on Windows.

Also I did some experiments with coalescing SG lists in the Opteron IOMMU
some time ago. With a MPT fusion controller and forcing all SG lists
through the IOMMU so that the SCSI controller always only contiguous mappings
I saw ~5% improvement on some IO tests.

Unfortunately there are some problems that doesn't allow to enable
this unconditionally. But it gives strong evidence that MPT Fusion prefers
shorter SG lists too.

So it seems to be worthwhile to optimize for shorter SG lists.

Ideally the Linux IO patterns would look similar to the Windows IO patterns,
then we could reuse all the optimizations the controller vendors
did for Windows :)
 
-Andi

  reply	other threads:[~2005-01-25  7:39 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-20 10:13 [PATCH] Avoiding fragmentation through different allocator Mel Gorman
2005-01-21 14:28 ` Marcelo Tosatti
2005-01-22 21:48   ` Mel Gorman
2005-01-22 21:59     ` Marcelo Tosatti
2005-01-23 13:28       ` Marcelo Tosatti
2005-01-24 13:28       ` Mel Gorman
2005-01-24 12:29         ` Marcelo Tosatti
2005-01-24 16:44           ` James Bottomley
2005-01-24 15:49             ` Marcelo Tosatti
2005-01-24 20:36               ` James Bottomley
2005-01-24 20:47             ` Steve Lord
2005-01-25  7:39               ` Andi Kleen [this message]
2005-01-24 19:55           ` Grant Grundler
  -- strict thread matches above, loose matches on Subject: below --
2005-01-25 14:02 Mukker, Atul
2005-01-25 14:17 ` Steve Lord
2005-01-25 14:27   ` Christoph Hellwig
2005-01-25 14:49     ` Andi Kleen
2005-01-25 14:56 ` Andi Kleen
2005-01-25 16:12   ` Mel Gorman
2005-01-25 18:50 ` Grant Grundler
2005-01-20 10:12 Mel Gorman

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=m1mzuyt0ss.fsf@muc.de \
    --to=ak@muc.de \
    --cc=grundler@parisc-linux.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lord@xfs.org \
    --cc=marcelo.tosatti@cyclades.com \
    --cc=mel@csn.ul.ie \
    --cc=wli@holomorphy.com \
    /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;
as well as URLs for NNTP newsgroup(s).