On 01/27/2015 01:24 PM, Andrew Morton wrote:
On Tue, 27 Jan 2015 08:24:28 -0800 Guenter Roeck <linux@xxxxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
