Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp6599374pxb; Wed, 17 Feb 2021 08:29:29 -0800 (PST) X-Google-Smtp-Source: ABdhPJxcibRyO4o2uasKELGcrhtRbw3Bc/F5YTr6d2SUjgOCu6e30oRQ8BFuFjMzJK49mqBQvfR+ X-Received: by 2002:a17:906:b252:: with SMTP id ce18mr12652932ejb.336.1613579369422; Wed, 17 Feb 2021 08:29:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1613579369; cv=none; d=google.com; s=arc-20160816; b=ONPZ56fa/uuMHBXQWluS8GvxsloQD84j/gWlDPu6n238PzL7ka17+2Mx6lokfZPqmt p3pdLDT3Mp6/N0vtCwDDiBauCj6/q8MrKLt+tVAcYa93nkgCL1/HLnVn5mtiwyN2A5m5 Ps5dNaMwYUotwiJwZvAzSLVHbRGO9c8NsILDuXtmGzkJ1T2keT8z+UOP1VFXIHXrJbMI nzGF36eKAEAVsNG/DYzbzJ/Rz1ICsEkXPib0j+yicKvT9D0o94xoe4E+/1buDfTlLZc0 azYCuziVrrdVo16gJ8jbDze/q8fKJlwmHwqmqdkWOn8JgH9AcZzg1oZxJz91QoyBelig YPjw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=fqY3aX+LcVTJX1gt4GvTFj3mpGHf8hCtl9l3H4cgEMs=; b=ngR0kMb9iFfDddXblXtIAtGXRowEFt5pLU2p3WUVRTIPkFx2zt2FpzociC/8lqeLWr YzM1Ijx6YN70zk3KlNvM6+cBn9RUa2R73l4JeGD1QgIR2Zmacsz0Z5i9F/k1CvUltWyS sFpC6ZuPZylexAdHer/GTeEnCjgGNDCjl+2hcB/Om3D083OjZ/JIcbJw17c7kqLLNJxr GeHDQJq20OuQMd2+PyDX33KFP1RIc9XLi55AGbZWu8y+LNNwjEJ0ginR9ZECBYBXSEY1 DXEzTRHt/JvAhuUUVFmu5G3oYpVxV3K+hOdmZ4b3EcLPPlRa7RePeacneanFc9GWQEXa lJPg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=bhhQeOko; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ay10si1768685ejb.105.2021.02.17.08.29.04; Wed, 17 Feb 2021 08:29:29 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=bhhQeOko; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233128AbhBQQZt (ORCPT + 99 others); Wed, 17 Feb 2021 11:25:49 -0500 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]:60663 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233070AbhBQQZr (ORCPT ); Wed, 17 Feb 2021 11:25:47 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1613579060; h=from:from:reply-to:subject:subject: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=fqY3aX+LcVTJX1gt4GvTFj3mpGHf8hCtl9l3H4cgEMs=; b=bhhQeOko8HkD7Jo/+LpuRBUUkdsFCk1nrHPuJCYP53TQe4JeleIt2KaTwT/oo+qFMEFFb7 e677WRrLah8KYQWG7QlXRYF2ebreGVRhpJ3v3QwSxjCsvyxYidUTN5+apSnnrtFodbfQ/m FzQbxtthX9vpiEYMebk23KRsL4vDah8= Received: from mail-qv1-f70.google.com (mail-qv1-f70.google.com [209.85.219.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-266-1zkNcTtfMO2sIgxGu4LKxw-1; Wed, 17 Feb 2021 11:24:18 -0500 X-MC-Unique: 1zkNcTtfMO2sIgxGu4LKxw-1 Received: by mail-qv1-f70.google.com with SMTP id n8so7291701qvo.18 for ; Wed, 17 Feb 2021 08:24:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=fqY3aX+LcVTJX1gt4GvTFj3mpGHf8hCtl9l3H4cgEMs=; b=UbJ2EtE2scbgtgQ8/12YLOJAnHrjNwzJLjOn1inJU3YnTG7sg/AlOdOzHzGgfbn/O0 DNOMJDxDvn9sIC0NbGir5Q8uHL4gam5Cx6aH5dmQLJiyqroGyk7j01m0kcO3D9gtupuS EjaCVUmpJ+xtJ1qFWw46EwrL00Nqr+5qEWQas0UkVw4CkpSmNX6T0FAPMcUHYSfkI8Sd PL23WCSDZ9ePibnHB7qM2qYxz9F9NJxPvd2nnJNiWckhruKLdKlh+cNfwQ4DG+GXq9tU ig+F9Ku3ee0fmSyyoJyXeJ8KYE44+aYnKIyokS3tnt7wINO29AQulfjrtrKHQn8I8uSb CekA== X-Gm-Message-State: AOAM532aap9klNpe5X+qL5b1aWV4dKMPJGNC3Fp1qJe7HZ2kFV+PHbC6 plocfVDL7yrBve+jl0yIPnrBtEP7cxdwBUz5hzCkMJjylqQdz+NCiwlU+/L7FrAFVFm/Fr5OR1Y bWSaf65sJZZNkZZmEot8ipQpr X-Received: by 2002:ac8:59d6:: with SMTP id f22mr61290qtf.230.1613579058312; Wed, 17 Feb 2021 08:24:18 -0800 (PST) X-Received: by 2002:ac8:59d6:: with SMTP id f22mr61266qtf.230.1613579058053; Wed, 17 Feb 2021 08:24:18 -0800 (PST) Received: from xz-x1 (bras-vprn-toroon474qw-lp130-20-174-93-89-182.dsl.bell.ca. [174.93.89.182]) by smtp.gmail.com with ESMTPSA id k129sm1919411qkf.108.2021.02.17.08.24.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 17 Feb 2021 08:24:17 -0800 (PST) Date: Wed, 17 Feb 2021 11:24:15 -0500 From: Peter Xu To: Mike Kravetz Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-s390@vger.kernel.org, shu wang , Axel Rasmussen , Andrea Arcangeli , Heiko Carstens , Alexey Dobriyan , Matthew Wilcox , Michel Lespinasse , Andrew Morton Subject: Re: [RFC PATCH 1/5] hugetlb: add hugetlb helpers for soft dirty support Message-ID: <20210217162415.GA6519@xz-x1> References: <20210211000322.159437-1-mike.kravetz@oracle.com> <20210211000322.159437-2-mike.kravetz@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20210211000322.159437-2-mike.kravetz@oracle.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 10, 2021 at 04:03:18PM -0800, Mike Kravetz wrote: > Add interfaces to set and clear soft dirty in hugetlb ptes. Make > hugetlb interfaces needed for /proc clear_refs available outside > hugetlb.c. > > arch/s390 has it's own version of most routines in asm-generic/hugetlb.h, > so add new routines there as well. > > Signed-off-by: Mike Kravetz > --- > arch/s390/include/asm/hugetlb.h | 30 ++++++++++++++++++++++++++++++ > include/asm-generic/hugetlb.h | 30 ++++++++++++++++++++++++++++++ > include/linux/hugetlb.h | 1 + > mm/hugetlb.c | 10 +--------- > 4 files changed, 62 insertions(+), 9 deletions(-) > > diff --git a/arch/s390/include/asm/hugetlb.h b/arch/s390/include/asm/hugetlb.h > index 60f9241e5e4a..b7d26248fb1c 100644 > --- a/arch/s390/include/asm/hugetlb.h > +++ b/arch/s390/include/asm/hugetlb.h > @@ -105,6 +105,11 @@ static inline pte_t huge_pte_mkdirty(pte_t pte) > return pte_mkdirty(pte); > } > > +static inline pte_t huge_pte_mkyoung(pte_t pte) > +{ > + return pte_mkyoung(pte); > +} > + > static inline pte_t huge_pte_wrprotect(pte_t pte) > { > return pte_wrprotect(pte); > @@ -115,9 +120,34 @@ static inline pte_t huge_pte_modify(pte_t pte, pgprot_t newprot) > return pte_modify(pte, newprot); > } > > +static inline bool huge_pte_soft_dirty(pte_t pte) > +{ > + return pte_soft_dirty(pte); > +} > + > +static inline pte_t huge_pte_clear_soft_dirty(pte_t pte) > +{ > + return pte_clear_soft_dirty(pte); > +} > + > +static inline pte_t huge_pte_swp_clear_soft_dirty(pte_t pte) > +{ > + return pte_swp_clear_soft_dirty(pte); > +} > + Indeed asm/hugetlb.h of s390 didn't include asm-generic/hugetlb.h as what was normally done by asm/hugetlb.h of other archs. Do you know why it's special? E.g. huge_pte_wrprotect() of s390 version is actually the same of the default version. When I looked at the huge_pte_wrprotect() I also see that there seems to have no real user of __HAVE_ARCH_HUGE_PTE_WRPROTECT. Not sure whether it can be dropped. My gut feeling is that s390 should also include asm-generic/hugetlb.h but only redefine the helper only if necessary, since I see no point defining the same helper multiple times. > static inline bool gigantic_page_runtime_supported(void) > { > return true; > } > > +#if !defined(__HAVE_ARCH_FLUSH_HUGETLB_TLB_RANGE) && !defined(MODULE) > +#include > + > +static inline void flush_hugetlb_tlb_range(struct vm_area_struct *vma, > + unsigned long start, unsigned long end) > +{ > + flush_tlb_range(vma, start, end); > +} > +#endif Similar question here, only ppc defined __HAVE_ARCH_FLUSH_HUGETLB_TLB_RANGE, so IIUC it means s390 should simply use the default version, and it'll be great if we don't need to redefine it here. Thanks, -- Peter Xu