* Toshi Kani <toshi.kani@xxxxxx> wrote: > On Wed, 2015-02-18 at 21:44 +0100, Ingo Molnar wrote: > > * Toshi Kani <toshi.kani@xxxxxx> wrote: > > > > > This patch implements huge I/O mapping capability interfaces on x86. > > > > > +#ifdef CONFIG_HUGE_IOMAP > > > +#ifdef CONFIG_X86_64 > > > +#define IOREMAP_MAX_ORDER (PUD_SHIFT) > > > +#else > > > +#define IOREMAP_MAX_ORDER (PMD_SHIFT) > > > +#endif > > > +#endif /* CONFIG_HUGE_IOMAP */ > > > > > +#ifdef CONFIG_HUGE_IOMAP > > > > Hm, so why is there a Kconfig option for this? It just > > complicates things. > > > > For example the kernel already defaults to mapping itself > > with as large mappings as possible, without a Kconfig entry > > for it. There's no reason to make this configurable - and > > quite a bit of complexity in the patches comes from this > > configurability. > > This Kconfig option was added to disable this feature in > case there is an issue. [...] If bugs are found then they should be fixed. > [...] That said, since the patchset also added a new > nohugeiomap boot option for the same purpose, I agree > that this Kconfig option can be removed. So, I will > remove it in the next version. > > An example of such case is with multiple MTRRs described > in patch 0/7. So the multi-MTRR case should probably be detected and handled safely? Thanks, Ingo -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx"> email@xxxxxxxxx </a>