Date: Wed, 2 Jul 2003 14:05:49 -0400 (EDT)
From: Rik van Riel <riel@redhat.com>
To: Andrea Arcangeli <andrea@suse.de>
cc: "Martin J. Bligh" <mbligh@aracnet.com>, Mel Gorman <mel@csn.ul.ie>,
       Linux Memory Management List <linux-mm@kvack.org>,
       Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: What to expect with the 2.6 VM
In-Reply-To: <20030702174700.GJ23578@dualathlon.random>
Message-ID: <Pine.LNX.4.44.0307021401570.31191-100000@chimarrao.boston.redhat.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1353
Lines: 35

On Wed, 2 Jul 2003, Andrea Arcangeli wrote:

> So ether we declare 32bit archs obsolete in production with 2.6, or we
> drop rmap behind remap_file_pages.

> Something has to change since IMHO in the current 2.5.73 remap_file_pages
> is nearly useless.

Agreed.  What we did for a certain unspecified kernel tree
at Red Hat was the following:

1) limit sys_remap_file_pages functionality to shared memory
   segments on ramfs (unswappable) and tmpfs (mostly unswappable;))

2) have the VMAs with remapped pages in them marked VM_LOCKED

3) do not set up pte chains for the pages that get mapped with
   install_page

4) remove said pages from the LRU list, in the ramfs case, they're
   unswappable anyway so we shouldn't have the VM scan them

The only known user of sys_remap_file_pages was more than happy
to have the functionality limited to just what they actually need, 
in order to get simpler code with less overhead.

Lets face it, nobody is going to use sys_remap_file_pages for
anything but a database shared memory segment anyway. You don't
need to care about truncate or the other corner cases.

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