On 08/13/2012 02:58 PM, Tejun Heo wrote:
>
> Also, please mention the possibility of using smaller size memory
> mappings if e820 didn't align physical memory to GB boundary.
>
... as it generally won't.
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Hello,
On Mon, Aug 13, 2012 at 04:47:00PM -0500, Jacob Shin wrote:
> Currently direct mappings are created for [ 0 to max_low_pfn< and [ 4GB to max_pfn< backed by actual DRAM. This is fine for holes under 4GB which are covered
> by fixed and variable range MTRRs to be UC. However, we run into trou
Currently direct mappings are created for [ 0 to max_low_pfn<
---
arch/x86/include/asm/page_types.h |9
arch/x86/kernel/setup.c | 108 +++--
2 files changed, 101 insertions(+), 16 deletions(-)
diff --git a/arch/x86/include/asm/page_types.h
b/ar
On Sat, Aug 11, 2012 at 12:49:48PM -0700, Tejun Heo wrote:
> Hello, Jacob.
Hi,
>
> On Thu, Aug 09, 2012 at 04:23:05PM -0500, Jacob Shin wrote:
> > +struct range pfn_mapped[E820_X_MAX];
> > +int nr_pfn_mapped;
>
> Why aren't these __initdata? Are they gonna be used for other
> purposes?
Yes, t
On Sat, Aug 11, 2012 at 11:36:39AM -0700, H. Peter Anvin wrote:
> On 08/09/2012 03:03 PM, Yinghai Lu wrote:
> >
> >can you put those line in another function?
> >
> >setup_arch is way too big now.
> >
>
> I agree with this ... Jacob, could you rev the patch?
Yes of course, I'll send out the revis
Hello, Jacob.
On Thu, Aug 09, 2012 at 04:23:05PM -0500, Jacob Shin wrote:
> +struct range pfn_mapped[E820_X_MAX];
> +int nr_pfn_mapped;
Why aren't these __initdata? Are they gonna be used for other
purposes?
> +void add_pfn_range_mapped(unsigned long start_pfn, unsigned long end_pfn)
> +{
> +
On 08/09/2012 03:03 PM, Yinghai Lu wrote:
can you put those line in another function?
setup_arch is way too big now.
I agree with this ... Jacob, could you rev the patch?
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
On Thu, Aug 9, 2012 at 2:23 PM, Jacob Shin wrote:
> Currently direct mappings are created for [ 0 to max_low_pfn< and [ 4GB to max_pfn< backed by actual DRAM. This is fine for holes under 4GB which are covered
> by fixed and variable range MTRRs to be UC. However, we run into trouble
> on higher m
Currently direct mappings are created for [ 0 to max_low_pfn<
---
arch/x86/include/asm/page_types.h |9
arch/x86/kernel/setup.c | 87 +
2 files changed, 88 insertions(+), 8 deletions(-)
diff --git a/arch/x86/include/asm/page_types.h
b/arch
9 matches
Mail list logo
