From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752778AbbBRV52 (ORCPT ); Wed, 18 Feb 2015 16:57:28 -0500 Received: from mail-wi0-f180.google.com ([209.85.212.180]:61777 "EHLO mail-wi0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752478AbbBRV51 (ORCPT ); Wed, 18 Feb 2015 16:57:27 -0500 Date: Wed, 18 Feb 2015 22:57:22 +0100 From: Ingo Molnar To: Toshi Kani Cc: akpm@linux-foundation.org, hpa@zytor.com, tglx@linutronix.de, mingo@redhat.com, arnd@arndb.de, linux-mm@kvack.org, x86@kernel.org, linux-kernel@vger.kernel.org, Elliott@hp.com Subject: Re: [PATCH v2 6/7] x86, mm: Support huge I/O mappings on x86 Message-ID: <20150218215722.GA27863@gmail.com> References: <1423521935-17454-1-git-send-email-toshi.kani@hp.com> <1423521935-17454-7-git-send-email-toshi.kani@hp.com> <20150218204414.GA20943@gmail.com> <1424294020.17007.21.camel@misato.fc.hp.com> <20150218211555.GA22696@gmail.com> <1424295209.17007.34.camel@misato.fc.hp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1424295209.17007.34.camel@misato.fc.hp.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Toshi Kani wrote: > On Wed, 2015-02-18 at 22:15 +0100, Ingo Molnar wrote: > > * Toshi Kani wrote: > > > > > On Wed, 2015-02-18 at 21:44 +0100, Ingo Molnar wrote: > > > > * Toshi Kani 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. Well, why not option D): D) detect unaligned requests and reject them ? Thanks, Ingo