xfs
[Top] [All Lists]

Re: Contribution to XFS on Linux <Support block sizes larger than the pa

To: Nathan Scott <nathans@xxxxxxx>
Subject: Re: Contribution to XFS on Linux <Support block sizes larger than the page size>
From: Andi Kleen <ak@xxxxxxx>
Date: 30 Sep 2005 14:20:34 +0200
Cc: linux-xfs@xxxxxxxxxxx, chandan.talukdar@xxxxxxxxx
In-reply-to: <20050929230058.GD823@frodo>
References: <433C5DEE.6020306@xxxxxxxxx> <20050929230058.GD823@frodo>
Sender: linux-xfs-bounce@xxxxxxxxxxx
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3
Nathan Scott <nathans@xxxxxxx> writes:

The main problem here is that this is more a Linux VM limitation than
a XFS limitation.

> The first way would be to allow the PAGE_CACHE_SIZE to be increased,
> which then reduces the problem to ensuring the increased page size
> covers all interesting blocksizes (the core XFS code, & XFS on IRIX,
> allows blocksizes in powers of 2 between 512 bytes to 64 kilobytes
> currently).

I don't think it would be a good idea. Allocating so many pages
with order > 0 would very likely bring the VM into a nervous
breakdown. At least you would need to fix the fragmentation 
in there first (there have been some approaches for this, but nothing
in mainline) 

Increasing PAGE_SIZE too would avoid that, but that would require
fixing the low level code in each architectures that maps pages from
page cache into user processes.  That would be probably a good thing
(there has been long talk to have larger softpagesizes on i386/x86-64
because it's not really efficient to manage multiple GB of memory in
4K pieces), but is definitely major work. There have been patches for
that in the past, but they never were remotely usable and quite
complex.

> 
> Last time I discussed this with Christoph (a long time back now),
> I think he favoured the first approach above.  I suspect the NTFS

I don't see how you can make it work without major effort.

-Andi


<Prev in Thread] Current Thread [Next in Thread>