lkml.org 
[lkml]   [2000]   [Mar]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: HIGH MEMORY access
Date
This is changing.  The new patches will be reclaim-enabled, so those pages
will be mapped, and the max_pfn-class variables will reflect their presence.

Nathan


> -----Original Message-----
> From: Manfred Spraul [mailto:manfreds@colorfullife.com]
> Sent: Friday, March 03, 2000 8:32 AM
> To: Ingo Molnar
> Cc: Lyle Coder; sct@redhat.com; linux-kernel@vger.rutgers.edu
> Subject: Re: HIGH MEMORY access
>
>
> Ingo Molnar wrote:
> >
> > On Fri, 3 Mar 2000, Manfred Spraul wrote:
> >
> > > Now I'm confused: I thought that ioremap() should be used
> for reserved
> > > memory, and kmap() for normal memory (e820: ram) with
> > > page->virtual==NULL.
> >
> > well you can use kmap() for anything, not just high memory.
>
> kmap() assumes that a "struct page" exists.
>
> It's not guaranteed that a "struct page" exists for reserved memory:
> this could happen if you boot with "mem=32M", or if the ACPI
> tables are
> the last element in the e820 map:
>
> * max_pfn is set to the end if the last usable block.
> * then the ACPI tables follow --> they are behind max_pfn -->
> behind the
> end of mem_map.
>
> Not everyone has 8 GB memory :-(
>
> --
> Manfred
>
> -
> 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/
>

-
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:56    [W:0.040 / U:1.184 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site