Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp343913ybi; Tue, 16 Jul 2019 21:39:01 -0700 (PDT) X-Google-Smtp-Source: APXvYqxxlswTuoLcVm4XXezo1jb0zO2nNZH+A9R7Jb3GD2GtCNqoKSgUCTUS4uk7+9zs4veYiYH7 X-Received: by 2002:a17:90a:8c0c:: with SMTP id a12mr41443640pjo.67.1563338341346; Tue, 16 Jul 2019 21:39:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1563338341; cv=none; d=google.com; s=arc-20160816; b=LI2Uh/0l2p0nhNFq+SO8249suWo4Oo4SuOesc9kajb+NDZuJnodfgqnTdIlsmA4jui 2sQAeYG+LmIZTLSoK9H6womlkXqpTAZ5c5EfQOV79biGDYgeiz4QF9wTSToDHa7nnQGm aQtd1WLMyKY3YBkZf8tMst/QRsqW+SEJeeQt15tnwvgj/g5m2jizqwlbk9TMw11lEuxL TuokQpwZB1pYYGEwc2z0KmwfDP26uV55TjCh0QBFpndXR/rG9drLwApIpW/A1OeONtXZ 7+cqctm5f3amSMzNjkDrE9gT6jOmwkbBF3QDe9xq+MA3A2QJCCqbrnjpXn5idHroErDD JzWA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=7NeqCbr6vMa0lvTgpBXKduJdSQr0P8chsTYZciovDGk=; b=ucbaLrE9gF/DLn2ICBXZuYdED2aHVqVAUJn9gK7bxc1WqL6c1xAV+3qTRadnoj1GS8 Av97AUjFhofs4nWbNM2CVME/tKxrZFsJRXEChiFX+KpE/31jHGfXnKZEe+i7bJ3DelQJ KX9kiwgsG1kOvN2OzzzKLIoA9ymnTQatLIZlSVaOZARCNsCvLZsGS767+oSQG/NKnkaH QjhjYJNH/T4R5tL+za3YvTjWIuzytU0ohqcdwFqVug7wryzcjUCK2nom9SYswEmmq7hX elR4XdKUScgfkqQpUnI251jFF7JiKkLF5BEypTU7BsDDfWDnt8KiPbRIWg5fBJQFOZeG jLoQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id ba9si20485517plb.308.2019.07.16.21.38.44; Tue, 16 Jul 2019 21:39:01 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726056AbfGQEi1 (ORCPT + 99 others); Wed, 17 Jul 2019 00:38:27 -0400 Received: from verein.lst.de ([213.95.11.211]:47036 "EHLO verein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725799AbfGQEi0 (ORCPT ); Wed, 17 Jul 2019 00:38:26 -0400 Received: by verein.lst.de (Postfix, from userid 2407) id 416C168B05; Wed, 17 Jul 2019 06:38:24 +0200 (CEST) Date: Wed, 17 Jul 2019 06:38:24 +0200 From: Christoph Hellwig To: John Hubbard Cc: Christoph Hellwig , Ralph Campbell , linux-mm@kvack.org, linux-kernel@vger.kernel.org, willy@infradead.org, Vlastimil Babka , Christoph Lameter , Dave Hansen , =?iso-8859-1?B?Suly9G1l?= Glisse , "Kirill A . Shutemov" , Lai Jiangshan , Martin Schwidefsky , Pekka Enberg , Randy Dunlap , Andrey Ryabinin , Jason Gunthorpe , Andrew Morton , Linus Torvalds Subject: Re: [PATCH 1/3] mm: document zone device struct page reserved fields Message-ID: <20190717043824.GA4755@lst.de> References: <20190717001446.12351-1-rcampbell@nvidia.com> <20190717001446.12351-2-rcampbell@nvidia.com> <26a47482-c736-22c4-c21b-eb5f82186363@nvidia.com> <20190717042233.GA4529@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jul 16, 2019 at 09:31:33PM -0700, John Hubbard wrote: > OK, so just delete all the _zd_pad_* fields? Works for me. It's misleading to > calling something padding, if it's actually unavailable because it's used > in the other union, so deleting would be even better than commenting. > > In that case, it would still be nice to have this new snippet, right?: I hope willy can chime in a bit on his thoughts about how the union in struct page should look like. The padding at the end of the sub-structs certainly looks pointless, and other places don't use it either. But if we are using the other fields it almost seems to me like we only want to union the lru field in the first sub-struct instead of overlaying most of it.