Received: by 2002:a6b:500f:0:0:0:0:0 with SMTP id e15csp145782iob; Tue, 17 May 2022 21:47:59 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwWjsm+6KFRzayBjZghrPeDwGvfKrcxOdhvORp+dMSQTGwEDUb5HpAnEypQ90GHV/lP456o X-Received: by 2002:a63:1953:0:b0:3c6:e5e:9190 with SMTP id 19-20020a631953000000b003c60e5e9190mr22115661pgz.286.1652849279780; Tue, 17 May 2022 21:47:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1652849279; cv=none; d=google.com; s=arc-20160816; b=z3OdapDqAgzLCph+hWb+Fox8F2InqxUYKF1+RhpzjMav9s1Z/kc1HCXV39yZ8lMu1D 0+0KSRXRFL/07tlFc2aMVODzn2aKt7vJVgrAg/HtrY4+KgYMh3G14U8l3E5Ik4BFR7YT 5GQI8KGZ/k/GIt4A86udtW6FNqX/sc+1JWE6lAkVFIdskqEsjz7EEsqecguR8HDw9VE+ agXBYUyQwDBHW0Z45gTgOoAVhb4gSyaiQCJaZV97dDR9TaoH8AaXMnQL7UF70lMHMvkU NszByjW7nxZodONKv7F/In2ErdRKSdg6B0NzpT9OJlccf5uvYzxtSbNPz0kapBL5MBZ8 BVxg== 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=syj4eKaIcozcbJiM1HOxwq1jTyd6lRf5m8mbrtKoVvs=; b=NbyHJILN8HISrTY99CUSh96XmFcpblEkIEi3N+nM2Oo0eM6Os5IZ6X2TgnlDMtCHjP zwP/giKStUDtucu9FxiDaaUjLWSnkbIT42meBjiC6wTu7w2HUNwR6TRG8gydkMPV37XQ nGq8CcQO8PNdid/p67P9ewjdCvVpjWINFdgvhqxZFbg+FQfo7WAwYAIl7RrewTjZg/+t YNRlmPpNrLuF48yTp/N8WVvHbCxa9hbpD3nmEDIZLOyW9C3/WN2Y4WpVYFQripCaiYyW 9263WbzG6neFNfVa5eP9tqpYRyx9lh86D1+5Vxe8yQKj+eGWW8RcXorgrxe2xVv0rncn fmwA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=kywTdcAs; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id 7-20020a631647000000b003c63d5fba78si1123650pgw.841.2022.05.17.21.47.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 May 2022 21:47:59 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@intel.com header.s=Intel header.b=kywTdcAs; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 7EF2462ED; Tue, 17 May 2022 20:59:34 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231396AbiEQWq7 (ORCPT + 99 others); Tue, 17 May 2022 18:46:59 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43654 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231219AbiEQWq5 (ORCPT ); Tue, 17 May 2022 18:46:57 -0400 Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A69563FD96 for ; Tue, 17 May 2022 15:46:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1652827616; x=1684363616; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=UPbb30qoGysGCMXmrylZxu9LDvbk/g1BrvZvUwm92gE=; b=kywTdcAsYEveIIeAjSNy2luiwIos45EkgsczZ6+Z0PEk4lB3eIKZ6cYa gDywFYzrIrvO1/GZiqHYrEMbAxf7UuBv6ocptJu3qpzQ8yVhSI7WGbWZi ASMou6C2LnFhrMjXd1hfBtDterpnU/xX9QVmnPIf5c5kbmeDfgvWXbEV1 TxLd4i0RjTYILkoBRi7R3LqfW/xI6lMpJfoKqGyGjg6lDx108aD8P8Ylr PZgilogDoVlv2+XFk1uQCNgJi9UlAEBpTzsBW6Nibd7ZOlQfGLgTuf3ba qXMcyw/zc4eXqYKzrk1wUHmYWT4e7hAP0tF4AOXV2NgTcHzVj6OouNlhD A==; X-IronPort-AV: E=McAfee;i="6400,9594,10350"; a="271309955" X-IronPort-AV: E=Sophos;i="5.91,233,1647327600"; d="scan'208";a="271309955" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 May 2022 15:46:56 -0700 X-IronPort-AV: E=Sophos;i="5.91,233,1647327600"; d="scan'208";a="597388075" Received: from hrong1-mobl.amr.corp.intel.com (HELO localhost) ([10.212.21.169]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 17 May 2022 15:46:55 -0700 Date: Tue, 17 May 2022 15:46:55 -0700 From: Ira Weiny To: Christoph Hellwig Cc: Dave Hansen , "H. Peter Anvin" , Dan Williams , Fenghua Yu , Rick Edgecombe , "Shankar, Ravi V" , linux-kernel@vger.kernel.org Subject: Re: [PATCH V10 33/44] kmap: Make kmap work for devmap protected pages Message-ID: References: <20220419170649.1022246-1-ira.weiny@intel.com> <20220419170649.1022246-34-ira.weiny@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 11, 2022 at 06:25:19PM -0700, Ira wrote: > On Thu, Apr 28, 2022 at 08:50:34AM -0700, Christoph Hellwig wrote: > > On Tue, Apr 19, 2022 at 10:06:38AM -0700, ira.weiny@intel.com wrote: > > > index a77be5630209..32ed07c2994b 100644 > > > --- a/include/linux/highmem-internal.h > > > +++ b/include/linux/highmem-internal.h > > > @@ -151,6 +151,8 @@ static inline void totalhigh_pages_add(long count) > > > > > > #else /* CONFIG_HIGHMEM */ > > > > > > +#include > > > > Uuuh, I'd really prefer to avoid having to pull in memremap.h into > > basically the whole kernel build. > > > > Fair enough. What should I call a header to store the new pgmap_set_*() calls? > > devmap_prot.h > > ? > > Or I could just add the calls into highmem-internal.h. That might be more > appropriate given the new direction of that interface. > > I think I'm leaning toward that vs adding another header. Ok there is a trade off here which I'm not sure is a good idea. In order to make kmap faster I carefully placed the devmap_protected() call completely inline.[1] This specifically checks the PGMAP_PROTECTION flag in dev_pagemap.[1] I see only 2 ways of not including memremap.h in highmem-internal.h. 1) Make this check a function call and place it in memremap.c 2) Move struct dev_pagemap (and it's dependencies) to another header. Number 2 negates any positive effect of splitting the header file. Number 1 is going to force some overhead on all ZONE_DEVICE pages if PMEM is in the system. Do you think the extra run time overhead is a reasonable trade off to eliminating the header? Ira [1] https://lore.kernel.org/lkml/20220419170649.1022246-29-ira.weiny@intel.com/