Re: mmotm 2015-01-22-15-04: qemu failures due to 'mm: account pmd page tables to the process'

[Guenter Roeck <linux@roeck-us.net>]

On 01/27/2015 01:24 PM, Andrew Morton wrote:
> On Tue, 27 Jan 2015 08:24:28 -0800 Guenter Roeck <linux@roeck-us.net> wrote:
>
>>> __PAGETABLE_PMD_FOLDED is defined during <asm/pgtable.h> which is not
>>> included into <linux/mm_types.h>. And we cannot include it here since
>>> many of <asm/pgtables> needs <linux/mm_types.h> to define struct page.
>>>
>>> I failed to come up with better solution rather than put nr_pmds into
>>> mm_struct unconditionally.
>>>
>>> One possible solution would be to expose number of page table levels
>>> architecture has via Kconfig, but that's ugly and requires changes to
>>> all architectures.
>>>
>> FWIW, I tried a number of approaches. Ultimately I gave up and concluded
>> that it has to be either this patch or, as you say here, we would have
>> to add something like PAGETABLE_PMD_FOLDED as a Kconfig option.
>
> It's certainly a big mess.  Yes, I expect that moving
> __PAGETABLE_PMD_FOLDED and probably PAGETABLE_LEVELS into Kconfig logic
> would be a good fix.
>
> Adding 8 bytes to the mm_struct (sometimes) isn't a huge issue, but
> it does make the kernel just a little bit worse.
>
> Has anyone taken a look at what the Kconfig approach would look like?
>

We would need something like

config PAGETABLE_PMD_FOLDED (or maybe PAGETABLE_NOPMD)
	def_bool y

for arc, arm64, avr32, cris, hexagon, metag, mips, mn10300, nios2, openrisc,
powerpc, score, sh, tile, um, unicore32, x86, xtensa, arm, m32r, and
microblaze. In several cases it would depend on secondary options,
such as CONFIG_ARM64_PGTABLE_LEVELS for arm64 or PAGETABLE_LEVELS for x86
and sh. PAGETABLE_LEVELS is not a configuration option (yet), so, yes,
that would have to be converted to a configuration option as well.

Overall a lot of complexity. Not really sure if that is worth the gain.
We would have to touch more than 20 Kconfig files plus about 20
source and include files which currently use _PAGETABLE_PMD_FOLDED.

> Possibly another fix for this would be to move mm_struct into its own
> header file, or something along those lines?
>

I suspect that might be just as messy. We would have to find all files
which actually need mm_struct and make sure that the new mm_struct.h
is included.

Not sure which approach is better. Sure, the 8 (or 4) bytes are annoying,
but I am not sure if the situation is bad enough to really bother.

Ultimately it seems there may be other variables in mm_struct which
could be made optional with much less effort, such as uprobes_state
or mmap_legacy_base.

Guenter