lkml.org 
[lkml]   [1999]   [Dec]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Getting big areas of memory, in 2.3.x?
Date
> 
> On Thu, 9 Dec 1999, Kanoj Sarcar wrote:
> > > Ingo Molnar wrote:
> > > > hm, does anyone have any conceptual problem with a new
> > > > allocate_largemem(pages) interface in page_alloc.c? It's not terribly hard
> > > > to scan all bitmaps for available RAM and mark the large memory area
> > > > allocated and remove all pages from the freelists. Such areas can only be
> > > > freed via free_largemem(pages). Both calls will be slow, so should be only
> > > > used at driver initialization time and such.
> > >
> > > Would this interface swap out user pages if necessary? That sort of
> > > interface would be great, and kill a number of hacks floating around out
> > > there.
> >
> > Swapping out user pages is not a sure shot thing unless Linux implements
> > reverse maps, so that we can track which page is being used by which pte.
> >
> > Without rmaps, any possible solution will be quite costly, if not an
> > outright hack, IMO.
>
> Not only that, we would also need to make
> sure that no kernel data pages are in the way.
>
> This means we'll need both reverse maps and
> a "real" zoned allocator. Not a 2.4 thing,
> I'm afraid :(
>

Well, at least in 2.3, kernel data (and page caches) are below 1G,
which means there's a lot of memory possible out there with
references only from user memory. Shm page references are
revokable too. Of course, in 2.5, things will probably change.

Kanoj

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:55    [W:0.140 / U:1.264 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site