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=-2.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no 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 6EDFBC433E0 for ; Tue, 5 Jan 2021 09:39:42 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id EF3D220757 for ; Tue, 5 Jan 2021 09:39:41 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org EF3D220757 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 483F98D0078; Tue, 5 Jan 2021 04:39:41 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 434318D006E; Tue, 5 Jan 2021 04:39:41 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2D4358D0078; Tue, 5 Jan 2021 04:39:41 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0192.hostedemail.com [216.40.44.192]) by kanga.kvack.org (Postfix) with ESMTP id 1752D8D006E for ; Tue, 5 Jan 2021 04:39:41 -0500 (EST) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id D827D181AC537 for ; Tue, 5 Jan 2021 09:39:40 +0000 (UTC) X-FDA: 77671224120.08.pull70_0405a1f274d7 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin08.hostedemail.com (Postfix) with ESMTP id C1EFA1819E76C for ; Tue, 5 Jan 2021 09:39:40 +0000 (UTC) X-HE-Tag: pull70_0405a1f274d7 X-Filterd-Recvd-Size: 5329 Received: from mail-lf1-f41.google.com (mail-lf1-f41.google.com [209.85.167.41]) by imf26.hostedemail.com (Postfix) with ESMTP for ; Tue, 5 Jan 2021 09:39:40 +0000 (UTC) Received: by mail-lf1-f41.google.com with SMTP id m25so71044072lfc.11 for ; Tue, 05 Jan 2021 01:39:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=i2OQSP8J84ALBsEAvjQwanW64SI0jNYanTtGLf4k6pk=; b=HEGsym/m2D3XZVcE9neY09JeOa1OmfrRG+7sxaN4x4ohoDWwDRZhrAArDwLi1fwV4b n7ARQzRJRBxeU9MGYfIaOUgtRVHULXYHuRsBrSNaFx2hoFpyN/mS6Ar/Fmxc/CnRVHM0 iYe3WEfAQ2ngN/QZ71I4wJSUA392S0RdXnP/SzoDDlfDsLw2fWw72J4b8+C/nC0zE8F4 4bBD9k5GX0teImtAHfy1NtKu0cRStrqyRN9hrubT6DcfI/UNEFT+pWW08AsqjyzIM865 fWXWogRlzqb8mKHNopuQoo4nz5yfhg+/b8VP9wN8R5kXtyzbYft+KEHFYGhasHWVkWOt Tcpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=i2OQSP8J84ALBsEAvjQwanW64SI0jNYanTtGLf4k6pk=; b=QLM+arndlOkkC1iATvYh25wkyavAl/jMj/ePTgl9qdt5YsI1AXObnfmp3HMBBvF/Ax KTRpWqR/2LnyVUW/f1x03LJXBL/wQCRo5MHeh3zRYsSrdgnoVRfnUi6CwWCN5hFRoWZo kRRZqvsn9eqJWVobw58VBIV9bMlq0CG5WDFN6LzQMMQMWOfaFTSPTtFJliDSR8Q8Ak3p Tk0mpntj/Mwd8Vsr+qhVBpUejQJFf6YfS0Q7sYH5Tc3A1sMb2FdwDcFXK68enFRO0fx0 imWNBsnz4xy2OaZHN6RtuUhGb9wFa0HErfdbdZ+NOC/V9TDrGxT8sCvMEFNxX+8qTieH Juow== X-Gm-Message-State: AOAM532Myp3lRbdMpWrcAFvm8FTmlUrdSEF7Wzhl5gxbrkP2Y66UjLHW Y1ijfz18/9xuaPJZ5u/xjvO1qflPreTGGAuS60I= X-Google-Smtp-Source: ABdhPJw3BgRE3gSvQc/Fh6/SsVhA0l3Jkse4uAPKN9VCXwMQx1yufbP7YdJ7cyJadCH5HsXqUASTq4WOcMkonn/2srY= X-Received: by 2002:a05:651c:22b:: with SMTP id z11mr36244037ljn.38.1609839578767; Tue, 05 Jan 2021 01:39:38 -0800 (PST) MIME-Version: 1.0 References: <43576DAD-8A3B-4691-8808-90C5FDCF03B7@redhat.com> <6bfcc500-7c11-f66a-26ea-e8b8bcc79e28@intel.com> <20210105092037.GY13207@dhcp22.suse.cz> <71953119-06ff-0bb8-1879-09e24bf80446@redhat.com> In-Reply-To: <71953119-06ff-0bb8-1879-09e24bf80446@redhat.com> From: Liang Li Date: Tue, 5 Jan 2021 17:39:27 +0800 Message-ID: Subject: Re: [RFC v2 PATCH 4/4] mm: pre zero out free pages to speed up page allocation for __GFP_ZERO To: David Hildenbrand Cc: Michal Hocko , Dave Hansen , Matthew Wilcox , Alexander Duyck , Mel Gorman , Andrew Morton , Andrea Arcangeli , Dan Williams , "Michael S. Tsirkin" , Jason Wang , Liang Li , linux-mm , LKML , virtualization@lists.linux-foundation.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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: On Tue, Jan 5, 2021 at 5:30 PM David Hildenbrand wrote: > > On 05.01.21 10:20, Michal Hocko wrote: > > On Mon 04-01-21 15:00:31, Dave Hansen wrote: > >> On 1/4/21 12:11 PM, David Hildenbrand wrote: > >>>> Yeah, it certainly can't be the default, but it *is* useful for > >>>> thing where we know that there are no cache benefits to zeroing > >>>> close to where the memory is allocated. > >>>> > >>>> The trick is opting into it somehow, either in a process or a VMA. > >>>> > >>> The patch set is mostly trying to optimize starting a new process. So > >>> process/vma doesn=E2=80=98t really work. > >> > >> Let's say you have a system-wide tunable that says: pre-zero pages and > >> keep 10GB of them around. Then, you opt-in a process to being allowed > >> to dip into that pool with a process-wide flag or an madvise() call. > >> You could even have the flag be inherited across execve() if you wante= d > >> to have helper apps be able to set the policy and access the pool like > >> how numactl works. > > > > While possible, it sounds quite heavy weight to me. Page allocator woul= d > > have to somehow maintain those pre-zeroed pages. This pool will also > > become a very scarce resource very soon because everybody just want to > > run faster. So this would open many more interesting questions. > > Agreed. > > > > > A global knob with all or nothing sounds like an easier to use and > > maintain solution to me. > > I mean, that brings me back to my original suggestion: just use > hugetlbfs and implement some sort of pre-zeroing there (worker thread, > whatsoever). Most vfio users should already be better of using hugepages. > > It's a "pool of pages" already. Selected users use it. I really don't > see a need to extend the buddy with something like that. > OK, since most people prefer hugetlbfs, I will send another revision for th= is. Thanks Liang