Re: Getting big areas of memory, in 2.3.x?
Kanoj Sarcar (firstname.lastname@example.org)
Thu, 9 Dec 1999 12:54:11 -0800 (PST)
> 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.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
Please read the FAQ at http://www.tux.org/lkml/