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=-8.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham 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 C1F74C433E0 for ; Mon, 4 Jan 2021 22:29:51 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 47FB52251E for ; Mon, 4 Jan 2021 22:29:51 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 47FB52251E Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id AD6908D0031; Mon, 4 Jan 2021 17:29:49 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A86A58D002D; Mon, 4 Jan 2021 17:29:49 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 976198D0031; Mon, 4 Jan 2021 17:29:49 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0041.hostedemail.com [216.40.44.41]) by kanga.kvack.org (Postfix) with ESMTP id 7EE418D002D for ; Mon, 4 Jan 2021 17:29:49 -0500 (EST) Received: from smtpin01.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 47C483629 for ; Mon, 4 Jan 2021 22:29:49 +0000 (UTC) X-FDA: 77669536098.01.prose65_0104c12274d3 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin01.hostedemail.com (Postfix) with ESMTP id 2533F10047846 for ; Mon, 4 Jan 2021 22:29:49 +0000 (UTC) X-HE-Tag: prose65_0104c12274d3 X-Filterd-Recvd-Size: 5187 Received: from mail-ej1-f43.google.com (mail-ej1-f43.google.com [209.85.218.43]) by imf16.hostedemail.com (Postfix) with ESMTP for ; Mon, 4 Jan 2021 22:29:48 +0000 (UTC) Received: by mail-ej1-f43.google.com with SMTP id lt17so38850189ejb.3 for ; Mon, 04 Jan 2021 14:29: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=d06d52mjMZ/nw2K/95kdxdCz9CRrwe6YL8rTpVP1OpB7AZ0myK2IJeguNC90+dfrSy tI6mbqFLpVsbIt7oKMAvzZKXtrEXVt12723KkHjpsVgxhr0sv39DHYbyXLDZ6at6Ke2C zX8oVqzhusCmR/nn1E8WYqmJB/PklQ9BDc9qm8a1iMj6cffUzP1aF3Tc9Ss8rBL9D7/u SgcuaCSnslFqEQmRuXnuuo9Ig0rpB7doXrHkGVjhrDNkwHEaeYxhCNXkHnosPdUxfq+C tClpXxsIGaHso6wEWkF5Wbq781vY1N+EmdvoluIKn2RMfJHgs6qpUgljq70qpVaUQCXD S4+g== X-Gm-Message-State: AOAM533vmYOKh/pJxHCPo2Xe2S71x5c1+9P6aROg/YBN6EClXb62uiu5 28RCVJ6kUiMrXdSZAe5T3k6+ZRg0xNm6wGVTn7D6jA== X-Google-Smtp-Source: ABdhPJxXfxM1BhY/5z030aM8G0Z4MMK7+AFboBuQ+Z7CQL9mSMsZkJ/4MtVxebNyRvqCTydGRunUvLgJHIogTDu1raY= 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 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 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.