[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.10.1401240941190.12665@nuc>
Date: Fri, 24 Jan 2014 09:44:20 -0600 (CST)
From: Christoph Lameter <cl@...ux.com>
To: Mel Gorman <mgorman@...e.de>
cc: Ric Wheeler <rwheeler@...hat.com>, linux-scsi@...r.kernel.org,
linux-ide@...r.kernel.org, linux-mm@...ck.org,
linux-fsdevel@...r.kernel.org, lsf-pc@...ts.linux-foundation.org,
linux-kernel@...r.kernel.org
Subject: Re: [Lsf-pc] [LSF/MM TOPIC] really large storage sectors - going
beyond 4096 bytes
On Fri, 24 Jan 2014, Mel Gorman wrote:
> That'd be okish for 64-bit at least although it would show up as
> degraded performance in some cases when virtually contiguous buffers were
> used. Aside from the higher setup, access costs and teardown costs of a
> virtual contiguous buffer, the underlying storage would no longer gets
> a single buffer as part of the IO request. Would that not offset many of
> the advantages?
It would offset some of that. But the major benefit of large order page
cache was the reduction of the number of operations that the kernel has to
perform. A 64k page contains 16 4k pages. So there is only one kernel
operation required instead of 16. If the page is virtually allocated then
the higher level kernel functions still only operate on one page struct.
The lower levels (bio) then will have to deal with the virtuall mappings
and create a scatter gather list. This is some more overhead but not much.
Doing something like this will put more stress on the defragmentation
logic in the kernel. In general I think we need more contiguous physical
memory.
--
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