lkml.org 
[lkml]   [2020]   [Oct]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [GIT PULL] x86/mm changes for v5.10
On Mon, Oct 12, 2020 at 03:07:45PM -0700, Linus Torvalds wrote:
> On Mon, Oct 12, 2020 at 10:24 AM Ingo Molnar <mingo@kernel.org> wrote:
> >
> > Do not sync vmalloc/ioremap mappings on x86-64 kernels.
> >
> > Hopefully now without the bugs!
>
> Let's hope so.
>
> If this turns out to work this time, can we do a similar preallocation
> of the page directories on 32-bit? Because I think now x86-32 is the
> only remaining case of doing that arch_sync_kernel_mappings() thing.
>
> Or is there some reason that won't work that I've lost sight of?

There were two reasons which made me decide to not pre-allocate on
x86-32:

1) The sync-level is the same as the huge-page level (PMD) on
both paging modes, so with large ioremap mappings the
synchronization is always needed. The huge ioremap mapping
could possibly be disabled without much performance impact on
x86-32.

2) The vmalloc area has a variable size and grows with less RAM
in the machine. And when the vmalloc area gets larger, more
pages are needed. Another factor is the configurable
vm-split. With a 1G/3G split on a machine with 128MB of RAM
there would be:

VMalloc area size (hole ignored): 3072MB - 128MB = 2944MB
PTE-pages needed (with PAE): 2944MB / 2MB/page = 1472 4k pages
Memory needed: 1472*4k = 5888kb

So on such machine the pre-allocation would need 5.75MB of
the 128MB RAM. Without PAE it is half of that. This is an
exotic configuration and I am not sure it matters much in
practice. It could also be worked around by setting limits
such as, for example, don't make the vmalloc area larger then
the avauilable memory in the system.

So pre-allocating has its implications. If we decide to pre-allocate on
x86-32 too, then we should be prepared for that fall-out of the higher
memory usage.

Regards,

Joerg

\
 
 \ /
  Last update: 2020-10-13 10:08    [W:0.064 / U:2.888 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site