Re: [00/17] Large Blocksize Support V3

[William Lee Irwin III <wli@holomorphy.com>]

On Thu, Apr 26, 2007 at 04:10:32AM -0600, Eric W. Biederman wrote:
>> You have HW_PAGE_SIZE != PAGE_SIZE.

On Thu, Apr 26, 2007 at 11:50:33PM +1000, David Chinner wrote:
> That's rather wasteful, though. Better to only use the large pages
> when the filesystem needs them rather than penalise all filesystems.

I found less of an issue with filesystem pagecache than with internal
fragmentation of anonymous memory when I did it. I'd expect, though,
that 4KB is probably too small and 64KB too large, at least for some
workloads. 16KB may do better; if not, 8KB may be worth doing just to
compensate for the larger sizes of pointers and unsigned longs in
struct page with respect to memory overhead so as not to regress vs.
32-bit, which isn't critical, but does have some cache and other
performance impacts.

Basically I found that without some intelligent method of divvying
out fragments of anonymous pages, pathological performance resulted.
The naive scheme of faulting at PAGE_SIZE-aligned boundaries created
swapstorms on memory-constrained hardware (e.g. laptops). Pagecache
was a second-order effect. It's not necessarily all that complex to
handle. One could easily recover the PAGE_SIZE == MMUPAGE_SIZE
behavior by keeping partially utilized anonymous pages cached in the mm
and handing out MMUPAGE_SIZE-sized fragments during COW/zerofill faults.
I had some sort of trouble with tracking the state for it, though I
don't remember what it was.

It's also notable that the two strategies (increasing base page size
and dealing with higher-order pages) don't clash all that much.


-- wli
-
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/