Received: by 2002:a05:6358:11c7:b0:104:8066:f915 with SMTP id i7csp781799rwl; Fri, 24 Mar 2023 01:43:56 -0700 (PDT) X-Google-Smtp-Source: AK7set/v77R8lqVp8TN3l/VedhNpG4RQltpIXni7WEUg1o75dK7Xfb1ybVjdkRYPPklYn+ktuoKO X-Received: by 2002:a05:6a20:98a7:b0:d9:dd69:47e3 with SMTP id jk39-20020a056a2098a700b000d9dd6947e3mr2289360pzb.23.1679647436225; Fri, 24 Mar 2023 01:43:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1679647436; cv=none; d=google.com; s=arc-20160816; b=uD2HdnqyVMsb5RQZW6GtlKKpn1RVtUc6bFOVC8MtGoQ5A6SDI9z7HtldEN5PCxojLq 8fZAr2OsX4eL5RtDdjMZyAk2iEfH1ZRnUG2znOTONPdaK/FEFYdf6sWwH317NODq9ci/ y82oLfsSwHCWNQynHV1/UDUAGmLk206TTqeOve8KAuOUJ83Sdi0bNADNNHyweaX833JE UKPdHounWgpPbQl/JuPWrylW/qBA2nsupVS/ttgWM08WmsC9zhr3dmqYm6asMlFsl4/S 0SqknfsxYNVN0KxD/OWWCggerwimcpIJsEJNk8/Zas0H7g0rBwdgW20OXag/IUAF3M5+ SyiQ== 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=6FnsbtwY1B8sPVCZAmhHvqVWvJAbJzIFlXms6iNspUI=; b=TzScjwyCVQVjszqWxjGA3omBlF/YGiQynNPpdCiumOkUzaKxhyVEEHi4+5yc6grsVH 7pkGW26LOTO2Ky2qrPh/sfSjHLeLHm4z0RULF531ewF0M4uFU5ZXj5/JNz0PCKAmTooa Iu3e3SVNGQBqxEjz/3D+B2YG9MMPKlTyP9lwCSkIUxOHuT6e3KLikdrFc51es4MTymC+ 4Fzem4Rphwgb0x5Kgz7NpcSlWXksoi4J9DDb1UltPt1Mop8qmufU2FeiKs/8Q9DrbtyC 49IvtMZHpAQNgAEiA0wLBJnfH29fYLLNuTR6Arfh7tyu4njsRgfI1oGFjyICo2BZDZH8 RQUg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.com header.s=susede1 header.b=FWO7t6jn; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=suse.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id 31-20020a63125f000000b0050b026c3aa7si19620594pgs.395.2023.03.24.01.43.44; Fri, 24 Mar 2023 01:43:56 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.com header.s=susede1 header.b=FWO7t6jn; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=suse.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231575AbjCXIhg (ORCPT + 99 others); Fri, 24 Mar 2023 04:37:36 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55314 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230029AbjCXIhf (ORCPT ); Fri, 24 Mar 2023 04:37:35 -0400 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 15E0C5B81 for ; Fri, 24 Mar 2023 01:37:33 -0700 (PDT) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id B099533777; Fri, 24 Mar 2023 08:37:32 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1679647052; 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=6FnsbtwY1B8sPVCZAmhHvqVWvJAbJzIFlXms6iNspUI=; b=FWO7t6jnASnlueUDIY+7y4XybdZ8cLn/U4DqkHTvKGbbpzg+VOwfRKt7tDXyssJPPEEyCF 28WGaEwlGzq97yMRRbwhX8UJmt+UD8g2c403LOBH0dc3sjHEaiYb91zb4BEqU+UvJ9UbY8 /ePG54a8aEvSe/Ekyd6VIHX+QUSRS+o= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 91DA0133E5; Fri, 24 Mar 2023 08:37:32 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id T+VUIUxhHWTkAgAAMHmgww (envelope-from ); Fri, 24 Mar 2023 08:37:32 +0000 Date: Fri, 24 Mar 2023 09:37:31 +0100 From: Michal Hocko To: Mike Rapoport Cc: linux-mm@kvack.org, Andrew Morton , Dave Hansen , Peter Zijlstra , Rick Edgecombe , Song Liu , Thomas Gleixner , Vlastimil Babka , linux-kernel@vger.kernel.org, x86@kernel.org Subject: Re: [RFC PATCH 1/5] mm: intorduce __GFP_UNMAPPED and unmapped_alloc() Message-ID: References: <20230308094106.227365-1-rppt@kernel.org> <20230308094106.227365-2-rppt@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230308094106.227365-2-rppt@kernel.org> X-Spam-Status: No, score=-2.5 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_PASS autolearn=unavailable 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 08-03-23 11:41:02, Mike Rapoport wrote: > From: "Mike Rapoport (IBM)" > > When set_memory or set_direct_map APIs used to change attribute or > permissions for chunks of several pages, the large PMD that maps these > pages in the direct map must be split. Fragmenting the direct map in such > manner causes TLB pressure and, eventually, performance degradation. > > To avoid excessive direct map fragmentation, add ability to allocate > "unmapped" pages with __GFP_UNMAPPED flag that will cause removal of the > allocated pages from the direct map and use a cache of the unmapped pages. > > This cache is replenished with higher order pages with preference for > PMD_SIZE pages when possible so that there will be fewer splits of large > pages in the direct map. > > The cache is implemented as a buddy allocator, so it can serve high order > allocations of unmapped pages. Why do we need a dedicated gfp flag for all this when a dedicated allocator is used anyway. What prevents users to call unmapped_pages_{alloc,free}? -- Michal Hocko SUSE Labs