On Sat, Dec 25 2004, William Lee Irwin III wrote:
> On Sat, 25 Dec 2004, Andrea Arcangeli wrote:
> >> the first place? If that happens it means you're under a lowmem
> >> shortage, something you apparently ruled out when you said
> >> lowmem_reserve couldn't help your workload.
>
> On Sat, Dec 25, 2004 at 12:59:10PM -0500, Rik van Riel wrote:
> > Let me explain a 3rd time:
> [...]
> > If you have any more questions as to why the bug happens, don't
> > hesitate to ask and I'll explain you why this problem happens.
>
> This is an old and well-known problem.
>
> Lifting the artificial lowmem restrictions on blockdev mappings
> (thereby nuking mapping->gfp_mask altogether) would resolve a number of
> problems, not that anything making that much sense could ever happen.
It should be lifted for block devices, it doesn't make any sense.
mapping->gfp_mask is still needed for things like loop though, so it
cannot be nuked.
--
Jens Axboe
On Sun, Jan 02, 2005 at 04:11:47PM +0100, Jens Axboe wrote:
> It should be lifted for block devices, it doesn't make any sense.
It cannot be lifted without:
1) creating aliasing between buffercache and blkdev pagecache
2) changing all fs to kmap around all buffercache accesses
2 would create an huge change (sure not a good idea during 2.6, 2.7 if
something). 1 would break lilo and tunefs and other things writing to a
superblock while the fs is mounted.
I effectively wrote it like 2 but I had to learn the hard way it broke
lilo in some weird configuration and IIRC Linus and Al fixed it very
nicely with current design.
There's no highmem and in turn no limit on 64bit in the first place, so
both efforts are worthless in the long term.
Jens Axboe <[email protected]> wrote:
>
> > Lifting the artificial lowmem restrictions on blockdev mappings
> > (thereby nuking mapping->gfp_mask altogether) would resolve a number of
> > problems, not that anything making that much sense could ever happen.
>
> It should be lifted for block devices, it doesn't make any sense.
Before we can permit blockdev pagecache to use highmem we must convert
every piece of code which accesses the cache to use kmap/kmap_atomic. If
you grep around for b_data you'll see there are a lot of such places.
Probably the migration could be done on a per-fs basis.
At some point in the past, I wrote:
>>> Lifting the artificial lowmem restrictions on blockdev mappings
>>> (thereby nuking mapping->gfp_mask altogether) would resolve a number of
>>> problems, not that anything making that much sense could ever happen.
Jens Axboe <[email protected]> wrote:
>> It should be lifted for block devices, it doesn't make any sense.
On Sun, Jan 02, 2005 at 12:03:24PM -0800, Andrew Morton wrote:
> Before we can permit blockdev pagecache to use highmem we must convert
> every piece of code which accesses the cache to use kmap/kmap_atomic. If
> you grep around for b_data you'll see there are a lot of such places.
> Probably the migration could be done on a per-fs basis.
I'd regard such an incremental conversion strategy as a prerequisite, and
would have no trouble working within such constraints.
-- wli