Re: [GIT PULL] x86/mm changes for v5.10

[Joerg Roedel <jroedel@suse.de>]

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