From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CD179C433E0 for ; Wed, 27 Jan 2021 10:20:43 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 613012072C for ; Wed, 27 Jan 2021 10:20:43 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 613012072C Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id B5C266B0006; Wed, 27 Jan 2021 05:20:42 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B0DB86B0008; Wed, 27 Jan 2021 05:20:42 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A4A1F6B000A; Wed, 27 Jan 2021 05:20:42 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0211.hostedemail.com [216.40.44.211]) by kanga.kvack.org (Postfix) with ESMTP id 9113D6B0006 for ; Wed, 27 Jan 2021 05:20:42 -0500 (EST) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 5D4401EE6 for ; Wed, 27 Jan 2021 10:20:42 +0000 (UTC) X-FDA: 77751161124.17.boy98_2d11f6827596 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin17.hostedemail.com (Postfix) with ESMTP id 3E4BA180D0184 for ; Wed, 27 Jan 2021 10:20:42 +0000 (UTC) X-HE-Tag: boy98_2d11f6827596 X-Filterd-Recvd-Size: 4073 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf05.hostedemail.com (Postfix) with ESMTP for ; Wed, 27 Jan 2021 10:20:41 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1611742840; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=ASjQD3e6RwZwXm35tKuOYLz+UbqyeCf/0FdsdUp4d+A=; b=MjrJgZgmwyXZqp1xptBq6z5ghgTvIWtUOucoeIznfMKkYBt4Cbp7NremW1haOkSjAEtpEA ImR7qQh0gorEhaLTPxJ7RVPhUmnkLeDMghbOp8gfCvWduOsCpzayUijBufCS+KU7HKlilA UUxnjTurMC45y43jJ2Nt7B+Egp2yUSE= Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 793F0AD2B; Wed, 27 Jan 2021 10:20:40 +0000 (UTC) Date: Wed, 27 Jan 2021 11:20:35 +0100 From: Michal Hocko To: Mike Kravetz Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, Naoya Horiguchi , Muchun Song , David Hildenbrand , Oscar Salvador , Matthew Wilcox , Miaohe Lin , Andrew Morton Subject: Re: [PATCH v3 1/5] hugetlb: use page.private for hugetlb specific page flags Message-ID: <20210127102035.GF827@dhcp22.suse.cz> References: <20210122195231.324857-1-mike.kravetz@oracle.com> <20210122195231.324857-2-mike.kravetz@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210122195231.324857-2-mike.kravetz@oracle.com> X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: [sorry for jumping in late] On Fri 22-01-21 11:52:27, Mike Kravetz wrote: > As hugetlbfs evolved, state information about hugetlb pages was added. > One 'convenient' way of doing this was to use available fields in tail > pages. Over time, it has become difficult to know the meaning or contents > of fields simply by looking at a small bit of code. Sometimes, the > naming is just confusing. For example: The PagePrivate flag indicates > a huge page reservation was consumed and needs to be restored if an error > is encountered and the page is freed before it is instantiated. The > page.private field contains the pointer to a subpool if the page is > associated with one. OK, I thought the page.private was abused more than for this very specific case. > In an effort to make the code more readable, use page.private to contain > hugetlb specific page flags. These flags will have test, set and clear > functions similar to those used for 'normal' page flags. More importantly, > an enum of flag values will be created with names that actually reflect > their purpose. This is definitely a step into the right direction! > In this patch, > - Create infrastructure for hugetlb specific page flag functions > - Move subpool pointer to page[1].private to make way for flags > Create routines with meaningful names to modify subpool field This makes some sense as well. It is really important that the primary state is stored in the head page. The respective data can be in tail pages. > - Use new HPageRestoreReserve flag instead of PagePrivate Much better! Although wouldn't HPageReserve be sufficient? The flag name doesn't really need to tell explicitly what to do with the reserve, right? Or would that be too confusing? > Conversion of other state information will happen in subsequent patches. > > Signed-off-by: Mike Kravetz I do not see any problems with the patch. I hope I haven't overlooked anything... Acked-by: Michal Hocko > --- > fs/hugetlbfs/inode.c | 12 ++------ > include/linux/hugetlb.h | 68 +++++++++++++++++++++++++++++++++++++++++ > mm/hugetlb.c | 48 +++++++++++++++-------------- > 3 files changed, 96 insertions(+), 32 deletions(-) -- Michal Hocko SUSE Labs