[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <94209678-bb55-2085-9cc8-f47bdf754ea4@intel.com>
Date: Thu, 26 Jan 2017 15:46:27 -0700
From: Dave Jiang <dave.jiang@...el.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: dave.hansen@...ux.intel.com, mawilcox@...rosoft.com,
linux-nvdimm@...1.01.org, linux-xfs@...r.kernel.org,
linux-mm@...ck.org, vbabka@...e.cz, jack@...e.com,
dan.j.williams@...el.com, linux-ext4@...r.kernel.org,
ross.zwisler@...ux.intel.com, kirill.shutemov@...ux.intel.com
Subject: Re: [PATCH v2 2/3] mm, x86: Add support for PUD-sized transparent
hugepages
On 01/26/2017 03:38 PM, Andrew Morton wrote:
> On Thu, 26 Jan 2017 10:09:53 -0700 Dave Jiang <dave.jiang@...el.com> wrote:
>
>> The current transparent hugepage code only supports PMDs. This patch
>> adds support for transparent use of PUDs with DAX. It does not include
>> support for anonymous pages. x86 support code also added.
>>
>> Most of this patch simply parallels the work that was done for huge PMDs.
>> The only major difference is how the new ->pud_entry method in mm_walk
>> works. The ->pmd_entry method replaces the ->pte_entry method, whereas
>> the ->pud_entry method works along with either ->pmd_entry or ->pte_entry.
>> The pagewalk code takes care of locking the PUD before calling ->pud_walk,
>> so handlers do not need to worry whether the PUD is stable.
>
> The patch adds a lot of new BUG()s and BG_ON()s. We'll get in trouble
> if any of those triggers. Please recheck everything and decide if we
> really really need them. It's far better to drop a WARN and to back
> out and recover in some fashion.
>
So I believe all the BUG() and BUG_ON() are replicated the same way that
the existing PMD support functions do with the same behavior. If we want
them to be different then we probably need to examine if the PMD code
(or maybe the PTE ones as well) need to be different also. I'm open to
suggestions from the experts on the cc list though.
Powered by blists - more mailing lists