[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.0703012137580.1768@schroedinger.engr.sgi.com>
Date: Thu, 1 Mar 2007 21:40:45 -0800 (PST)
From: Christoph Lameter <clameter@...r.sgi.com>
To: Nick Piggin <npiggin@...e.de>
cc: Andrew Morton <akpm@...ux-foundation.org>,
Mel Gorman <mel@...net.ie>, mingo@...e.hu,
jschopp@...tin.ibm.com, arjan@...radead.org,
torvalds@...ux-foundation.org, mbligh@...igh.org,
linux-mm@...ck.org, linux-kernel@...r.kernel.org
Subject: Re: The performance and behaviour of the anti-fragmentation related
patches
On Fri, 2 Mar 2007, Nick Piggin wrote:
> So what do you mean by efficient? I guess you aren't talking about CPU
> efficiency, because even if you make the IO subsystem submit larger
> physical IOs, you still have to deal with 256 billion TLB entries, the
> pagecache has to deal with 256 billion struct pages, so does the
> filesystem code to build the bios.
You do not have to deal with TLB entries if you do buffered I/O.
For mmapped I/O you would want to transparently use 2M TLBs if the
page size is large.
> So you are having problems with your IO controller's handling of sg
> lists?
We currently have problems with the kernel limits of 128 SG
entries but the fundamental issue is that we can only do 2 Meg of I/O in
one go given the default limits of the block layer. Typically the number
of hardware SG entrie is also limited. We never will be able to put a
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists