On Wed, 2015-02-18 at 22:15 +0100, Ingo Molnar wrote: > * Toshi Kani <[email protected]> wrote: > > > On Wed, 2015-02-18 at 21:44 +0100, Ingo Molnar wrote: > > > * Toshi Kani <[email protected]> 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.
Right. > > [...] 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? I considered two options to safely handle this case, i.e. option A) and B) described in the link below. https://lkml.org/lkml/2015/2/5/638 I thought about how much complication we should put into the code for an imaginable platform with a combination of new NVM (or large I/O range) and legacy MTRRs with multi-types & contiguous ranges. My thinking is that we should go with option C) for simplicity, and implement A) or B) later if we find it necessary. Thanks, -Toshi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
