lkml.org 
[lkml]   [2011]   [Jun]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [PATCH] x86_64: do not assume head_64.S used 4KB pages when !use_pse
Date
> From: Stefano Stabellini [mailto:stefano.stabellini@eu.citrix.com]
> Sent: 23. kesäkuuta 2011 18:20
> To: Penttilä Mika
> Cc: Stefano Stabellini; linux-kernel@vger.kernel.org
> Subject: RE: [PATCH] x86_64: do not assume head_64.S used 4KB pages
> when !use_pse
>
> On Thu, 23 Jun 2011, Penttilä Mika wrote:
> > > > And arch/x86/mm/init.c also has:
> > > >
> > > > #if defined(CONFIG_DEBUG_PAGEALLOC) || defined(CONFIG_KMEMCHECK)
> > > > /*
> > > > * For CONFIG_DEBUG_PAGEALLOC, identity mapping will use
> > > small pages.
> > > > * This will simplify cpa(), which otherwise needs to
> support
> > > splitting
> > > > * large pages into small in interrupt context, etc.
> > > > */
> > > > use_pse = use_gbpages = 0;
> > > > #else
> > > > use_pse = cpu_has_pse;
> > > > use_gbpages = direct_gbpages;
> > > > #endif
> > > >
> > > >
> > > > So big pages are also not used for DEBUG_PAGEALLOC and KMEMCHECK
> > > configs even if head_32.S did.
> > >
> > > Right, but that is not a problem because head_32.S always uses 4KB
> > > pages.
> >
> > We use large pages FOR PAE kernels on x86-32 there
> >
>
> Do you mean we use large pages for PAE kernels on x86_32 in
> arch/x86/mm/init.c:init_memory_mapping?
> That wouldn't be a problem for this patch.
>
> The problem I am trying to solve occurs when head_64.S doesn't allocate
> any pte pages because it is using 2MB pages, while init_memory_mapping
> wants to use 4KB pages (for example because the user set
> CONFIG_DEBUG_PAGEALLOC).
>
> So on x86_32 is not going to be an issue because head_32.S doesn't use
> 2MB or 4MB pages as far as I can tell, even if the hardware supports
> them.
> Please correct me if I am wrong but I don't see any _PAGE_PSE in
> head_32.S.


Yes you're right head_32.S doesn't do large pages, I remembered it would..

--Mika


\
 
 \ /
  Last update: 2011-06-23 18:29    [W:0.492 / U:0.080 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site