Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp14183239pxu; Mon, 4 Jan 2021 15:28:03 -0800 (PST) X-Google-Smtp-Source: ABdhPJzwn6qoh3Y57hXRFhTLNAB/R1jmGITvCFUJleVmfabOim5y8+PDiyJ9UbGSwiBUGA9uOljb X-Received: by 2002:a17:906:4146:: with SMTP id l6mr69178742ejk.341.1609802883400; Mon, 04 Jan 2021 15:28:03 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1609802883; cv=none; d=google.com; s=arc-20160816; b=fnPlfLEuEJw08hHwGRaEcJPeZB/VNSvKfoJRu5Xr/S2s25sgxVXy2LS5Ph9uXlYnVr gPHteWS134YQu9owtsmRX/X9NYGgnEedCeBIEe7VENY8X4dbFGUE2vVhhD84vVCkVfDl zNRNvqYIME8uqH+GSSAyjDDJKqRNKlyDrkZTlgLAPkympwtMsE0DL0l9qZY9a5sTeU9R +h6SgByitInJGoPiE+2etM4Y8XjXPx8tMa0ZuoZvkTKAJtLhcgzanmrkKl2knGtjDqxi GU+dDabuI/uEtdiLjIGWpWK+r/+TfEo+p/n7i3945NUuH1GM/s/xCmbVaGOpZQPcr9es QB1g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=bZYZtiZqtjiM5mTKJrFBVkfoUrE9/7TPDo+TfeeGsN0=; b=eqeFkEP9y1kz7PujpxGtydpfgb2PRPqLrEK4+Ggiv4pKz0e5cAMp42ZKOLSD0x9Pl/ Ipwg7Te+P9SM3TD40ok7CITk4kdrAheY22kYTizYx3UGMSVA34Jdc0rVC/jtbkpM5bGr uqSOy2vp0fBertqr71w5gX/EwdYt79o/8S525ZTuCuxJkGroec9qU5Z6Qsorv6+g03+V Qg91T2i5whtqvRNNXJTlaYwUiLMtUJNX3jP3886Q5REcSZT/PYd465XQj1KTgpMBOTOv uvpiNmxGruoWPtfYo0ydyHLjUkawxh0qPj9FhMpJyONUrOelKHOoG4AnznhONV+n4rDs 6EBA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=SZ0tfQHL; 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=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id i19si33010498edq.373.2021.01.04.15.27.40; Mon, 04 Jan 2021 15:28:03 -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=@intel-com.20150623.gappssmtp.com header.s=20150623 header.b=SZ0tfQHL; 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=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726475AbhADX02 (ORCPT + 99 others); Mon, 4 Jan 2021 18:26:28 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57956 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727473AbhADX01 (ORCPT ); Mon, 4 Jan 2021 18:26:27 -0500 Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7A119C061574 for ; Mon, 4 Jan 2021 15:25:47 -0800 (PST) Received: by mail-lf1-x136.google.com with SMTP id h22so68504376lfu.2 for ; Mon, 04 Jan 2021 15:25:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=bZYZtiZqtjiM5mTKJrFBVkfoUrE9/7TPDo+TfeeGsN0=; b=SZ0tfQHLhsr9W1ajzZ39FhUzRaxy3x+zBWBSD+fu8SGm84RUr8oeAtTXXk34EIqT80 tDMqqZ6IdhqCS6JSANuPqibcoPCEoly7svMmOTZFAPM2+CsDRFNM7PDMeYhE+m7oeIxf +8GSdXQNOjaF8R0tToPJnc0n0RUoTrRkrCGnHcNek2i5t/XbwHT1ZJH9ZFYOX5OQTl09 Tvhaup+6QcssSXygg5EhjaW6SkhdaAA9pFJYgBeZTethdmdHFkGzSKrHPaZpiN0srscY HEcLktaEA2rc8qprUWbvJ1yVRNnuoYCACG9cGgQxBit2TOzM4VehHDRkZC0hFtdJysbt 4KKQ== 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=bZYZtiZqtjiM5mTKJrFBVkfoUrE9/7TPDo+TfeeGsN0=; b=Pb7Zzk9LZAwvlk8hoQQR2GFvYRrgJaS3EPuwnM+lZIRfCEPT41fvFvYxS9cMM9XhkV /cpgGQa2oUGJNzkOB3KaLpuRJjLLnr/iI6XogTWSuLPEIaYtxBZ6h/I7vAk6CV5nkViz SkviQgGu9cSIdCzrV9+EqeqWZLVuN3Z22yDiTwJaP9EJdSmfKMlP2BT5p7zUvtNQP+bi FG2bkixk4ROM7h3VO+QnV1mXF6t+7fcms30SOLql/0tPfhGWezXeajux67AsMFX6sLUJ dPjX/LDOg3ZvkoVCklZggFuTv255NxAWP4uRDp3rtr6Cyv7vdlLn2BVNBLy+shQIosRH 5nmA== X-Gm-Message-State: AOAM531uer1PJIlBdVc4su0MCgdL27fr8bDaWHC5jmNgyxeaM6Emw2Zz 7YtSfmB7fz5Kp44wmc7B8QuRxCmY2IqN42k2saNyIUdTHF8= X-Received: by 2002:a17:906:edb2:: with SMTP id sa18mr65644898ejb.264.1609799386671; Mon, 04 Jan 2021 14:29:46 -0800 (PST) MIME-Version: 1.0 References: <43576DAD-8A3B-4691-8808-90C5FDCF03B7@redhat.com> In-Reply-To: <43576DAD-8A3B-4691-8808-90C5FDCF03B7@redhat.com> From: Dan Williams Date: Mon, 4 Jan 2021 14:29:40 -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: Dave Hansen , Matthew Wilcox , Alexander Duyck , Mel Gorman , Andrew Morton , Andrea Arcangeli , "Michael S. Tsirkin" , Jason Wang , Michal Hocko , Liang Li , Linux MM , Linux Kernel Mailing List , virtualization@lists.linux-foundation.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jan 4, 2021 at 12:11 PM David Hildenbrand wrote: > > > > Am 04.01.2021 um 20:52 schrieb Dave Hansen : > > > > =EF=BB=BFOn 1/4/21 11:27 AM, Matthew Wilcox wrote: > >>> On Mon, Jan 04, 2021 at 11:19:13AM -0800, Dave Hansen wrote: > >>> On 12/21/20 8:30 AM, Liang Li wrote: > >>>> --- a/include/linux/page-flags.h > >>>> +++ b/include/linux/page-flags.h > >>>> @@ -137,6 +137,9 @@ enum pageflags { > >>>> #endif > >>>> #ifdef CONFIG_64BIT > >>>> PG_arch_2, > >>>> +#endif > >>>> +#ifdef CONFIG_PREZERO_PAGE > >>>> + PG_zero, > >>>> #endif > >>>> __NR_PAGEFLAGS, > >>> > >>> I don't think this is worth a generic page->flags bit. > >>> > >>> There's a ton of space in 'struct page' for pages that are in the > >>> allocator. Can't we use some of that space? > >> > >> I was going to object to that too, but I think the entire approach is > >> flawed and needs to be thrown out. It just nukes the caches in extrem= ely > >> subtle and hard to measure ways, lowering overall system performance. > > > > 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 wher= e > > 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 pro= cess/vma doesn=E2=80=98t really work. > > I still wonder if using tmpfs/shmem cannot somehow be used to cover the o= riginal use case of starting a new vm fast (or rebooting an existing one in= volving restarting the process). If it's rebooting a VM then file-backed should be able to skip the zeroing because the stale data exposure is only to itself. If the memory is being repurposed to a new VM then the file needs to be reallocated / re-zeroed just like the anonymous case.