From: James Bottomley <jejb@steeleye.com>
To: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
Cc: 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: Mon, 24 Jan 2005 14:36:09 -0600 [thread overview]
Message-ID: <1106598969.5513.43.camel@mulgrave> (raw)
In-Reply-To: <20050124154927.GJ5925@logos.cnet>
On Mon, 2005-01-24 at 13:49 -0200, Marcelo Tosatti wrote:
> So is it valid to affirm that on average an operation with one SG element pointing to a 1MB
> region is similar in speed to an operation with 16 SG elements each pointing to a 64K
> region due to the efficient onboard SG processing?
it's within a few percent, yes. And the figures depend on how good the
I/O card is at it. I can imagine there are some wildly varying I/O
cards out there.
However, also remember that 1MB of I/O is getting beyond what's sensible
for a disc device anyway. The cable speed is much faster than the
platter speed, so the device takes the I/O into its cache as it services
it. If you overrun the cache it will burp (disconnect) and force a
reconnection to get the rest (effectively splitting the I/O up anyway).
This doesn't apply to arrays with huge caches, but it does to pretty
much everything else. The average disc cache size is only a megabyte or
so.
James
WARNING: multiple messages have this Message-ID (diff)
From: James Bottomley <jejb@steeleye.com>
To: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
Cc: 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: Mon, 24 Jan 2005 14:36:09 -0600 [thread overview]
Message-ID: <1106598969.5513.43.camel@mulgrave> (raw)
In-Reply-To: <20050124154927.GJ5925@logos.cnet>
On Mon, 2005-01-24 at 13:49 -0200, Marcelo Tosatti wrote:
> So is it valid to affirm that on average an operation with one SG element pointing to a 1MB
> region is similar in speed to an operation with 16 SG elements each pointing to a 64K
> region due to the efficient onboard SG processing?
it's within a few percent, yes. And the figures depend on how good the
I/O card is at it. I can imagine there are some wildly varying I/O
cards out there.
However, also remember that 1MB of I/O is getting beyond what's sensible
for a disc device anyway. The cable speed is much faster than the
platter speed, so the device takes the I/O into its cache as it services
it. If you overrun the cache it will burp (disconnect) and force a
reconnection to get the rest (effectively splitting the I/O up anyway).
This doesn't apply to arrays with huge caches, but it does to pretty
much everything else. The average disc cache size is only a megabyte or
so.
James
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>
next prev parent reply other threads:[~2005-01-24 20:43 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-01-20 10:13 [PATCH] Avoiding fragmentation through different allocator Mel Gorman
2005-01-20 10:13 ` Mel Gorman
2005-01-21 14:28 ` Marcelo Tosatti
2005-01-21 14:28 ` Marcelo Tosatti
2005-01-22 21:48 ` Mel Gorman
2005-01-22 21:48 ` Mel Gorman
2005-01-22 21:59 ` Marcelo Tosatti
2005-01-22 21:59 ` Marcelo Tosatti
2005-01-23 13:28 ` Marcelo Tosatti
2005-01-23 13:28 ` Marcelo Tosatti
2005-01-24 13:28 ` Mel Gorman
2005-01-24 13:28 ` Mel Gorman
2005-01-24 12:29 ` Marcelo Tosatti
2005-01-24 12:29 ` Marcelo Tosatti
2005-01-24 16:44 ` James Bottomley
2005-01-24 16:44 ` James Bottomley
2005-01-24 15:49 ` Marcelo Tosatti
2005-01-24 15:49 ` Marcelo Tosatti
2005-01-24 20:36 ` James Bottomley [this message]
2005-01-24 20:36 ` James Bottomley
2005-01-24 20:47 ` Steve Lord
2005-01-24 20:47 ` Steve Lord
2005-01-25 7:39 ` Andi Kleen
2005-01-25 7:39 ` Andi Kleen
2005-01-24 19:55 ` Grant Grundler
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:02 ` Mukker, Atul
2005-01-25 14:17 ` Steve Lord
2005-01-25 14:17 ` Steve Lord
2005-01-25 14:27 ` Christoph Hellwig
2005-01-25 14:27 ` Christoph Hellwig
2005-01-25 14:49 ` Andi Kleen
2005-01-25 14:49 ` Andi Kleen
2005-01-25 14:56 ` Andi Kleen
2005-01-25 14:56 ` Andi Kleen
2005-01-25 16:12 ` Mel Gorman
2005-01-25 16:12 ` Mel Gorman
2005-01-25 18:50 ` Grant Grundler
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=1106598969.5513.43.camel@mulgrave \
--to=jejb@steeleye.com \
--cc=grundler@parisc-linux.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.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 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.