Messages in this thread | | | Date | Wed, 25 Jun 2008 16:14:54 -0700 | From | "Yinghai Lu" <> | Subject | Re: [PATCH] x86: remove end_pfn in 64bit |
| |
On Wed, Jun 25, 2008 at 3:21 PM, Jeremy Fitzhardinge <jeremy@goop.org> wrote: > Yinghai Lu wrote: >> >> On Wed, Jun 25, 2008 at 2:31 PM, Jeremy Fitzhardinge <jeremy@goop.org> >> wrote: >> >>> >>> Ingo Molnar wrote: >>> >>>> >>>> * Yinghai Lu <yhlu.kernel@gmail.com> wrote: >>>> >>>> >>>> >>>>> >>>>> and use max_pfn directly. >>>>> >>>>> Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> >>>>> >>>>> >>>> >>>> applied to tip/x86/setup-memory - thanks Yinghai. I have picked up these >>>> patches: >>>> >>>> Ingo Molnar (1): >>>> Merge branch 'x86/setup-memory' >>>> >>>> Yinghai Lu (6): >>>> x86: fix e820_update_range size when overlapping >>>> x86: get max_pfn_mapped in init_memory_mapping >>>> x86: add table_top check for alloc_low_page in 64 bit >>>> x86: change size if e820_update/remove_range >>>> x86: numa 32 using apicid_2_node to get node for logical_apicid >>>> x86: remove end_pfn in 64bit >>>> >>>> >>> >>> Did you CC: this to me to indicate that "x86_64: replace end_pfn with >>> num_physpages" conflicts massively with this patch? Fortunately I don't >>> depend on it, so I don't mind much. >>> >>> How does "max_pfn" differ from "num_physpages"? Should one of them go as >>> well? >>> >> >> 64bit setup_arch assign num_physpages with end_pfn... >> > > I posted a patch to remove end_pfn and replace it with num_physpages > everywhere, which obviously clashed badly with your patch ;)
32bit has max_pfn, max_low_pfn, max_pfn_mapped...and min_low_pfn.
> >> and max_pfn is defined in linux/bootmem.h >> num_physpages is defined in linux/mm.h > > Do they contain separate values? Do they mean different things?
x86 64 bit that they are same. num_phypages = max_pfn 32 bit when HIGHMEM=y, it is same.num_phypages = max_pfn when HIGHMEM=n, num_phypages = max_low_pfn
YH
| |