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=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 B46BAC433E0 for ; Tue, 5 Jan 2021 09:56:26 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2BD2420739 for ; Tue, 5 Jan 2021 09:56:26 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2BD2420739 Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 562EB6B00B8; Tue, 5 Jan 2021 04:56:25 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 514186B00B9; Tue, 5 Jan 2021 04:56:25 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 402B68D006E; Tue, 5 Jan 2021 04:56:25 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0085.hostedemail.com [216.40.44.85]) by kanga.kvack.org (Postfix) with ESMTP id 282486B00B8 for ; Tue, 5 Jan 2021 04:56:25 -0500 (EST) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id E0CA9E0AF for ; Tue, 5 Jan 2021 09:56:24 +0000 (UTC) X-FDA: 77671266288.26.box95_0b11a4f274d8 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin26.hostedemail.com (Postfix) with ESMTP id BAB2C1804B66A for ; Tue, 5 Jan 2021 09:56:24 +0000 (UTC) X-HE-Tag: box95_0b11a4f274d8 X-Filterd-Recvd-Size: 2794 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf34.hostedemail.com (Postfix) with ESMTP for ; Tue, 5 Jan 2021 09:56:24 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1609840583; 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=QvOYoDvfxGPDWYxvtgGuddRRzjuOX66FxsdlUwuf/7k=; b=r+JgTbKMyJUR8zxupmmXMHeSyaBnY09RAVghmxV+yhGjgwYSyVBxnt3B1pB49AAy3ZhN9u Qlo5q9IazZJtecwvfprCh9eZIHe7An7vzG4qH7e1WFcAkdAMZMY7Nis6JsIAUrs+7eVpb0 EnT6NToW5grNyKZ7oIIqGYGT0urBWbw= Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id F16FBAE87; Tue, 5 Jan 2021 09:56:22 +0000 (UTC) Date: Tue, 5 Jan 2021 10:56:21 +0100 From: Michal Hocko To: David Hildenbrand Cc: Dave Hansen , Matthew Wilcox , Alexander Duyck , Mel Gorman , Andrew Morton , Andrea Arcangeli , Dan Williams , "Michael S. Tsirkin" , Jason Wang , Liang Li , linux-mm@kvack.org, linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org Subject: Re: [RFC v2 PATCH 4/4] mm: pre zero out free pages to speed up page allocation for __GFP_ZERO Message-ID: <20210105095621.GB13207@dhcp22.suse.cz> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <71953119-06ff-0bb8-1879-09e24bf80446@redhat.com> 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 05-01-21 10:29:45, David Hildenbrand wrote: > On 05.01.21 10:20, Michal Hocko wrote: [...] > > 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. Shifting background zeroying to hugetlb would solve the problem with the work accounting, right? Somebody has to pay for that work and piggy back on all other CPU consumers by default is not acceptable even when that is reduced to hugetlb. -- Michal Hocko SUSE Labs