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 34BD1C433DB for ; Mon, 4 Jan 2021 12:51:32 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id B288C207AE for ; Mon, 4 Jan 2021 12:51:31 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B288C207AE 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 DF6FA8D000D; Mon, 4 Jan 2021 07:51:30 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id DA7018D000A; Mon, 4 Jan 2021 07:51:30 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C6E4D8D000D; Mon, 4 Jan 2021 07:51:30 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id B27F28D000A for ; Mon, 4 Jan 2021 07:51:30 -0500 (EST) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 6DA438248068 for ; Mon, 4 Jan 2021 12:51:30 +0000 (UTC) X-FDA: 77668078740.26.egg28_4c08074274d0 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin26.hostedemail.com (Postfix) with ESMTP id 4C8591804B660 for ; Mon, 4 Jan 2021 12:51:30 +0000 (UTC) X-HE-Tag: egg28_4c08074274d0 X-Filterd-Recvd-Size: 3510 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf04.hostedemail.com (Postfix) with ESMTP for ; Mon, 4 Jan 2021 12:51:29 +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=1609764688; 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=FB8hy0U9RwYKVBKY1CojR4FapZx1ziXIahEY9it/cng=; b=OuLz91gDvfLpxzWsAlBiGbMZM6Pia2k8ev2LOZsYiMlx1v/WnHaWSHkS+w7rqSmORZG+27 Wk5cyIHHQhAe/FQQr+pOPXiiFpk5GJFf2bqvFEzghJ5HXjtFwE9Yb6hnSTbHJfXtqtCV7c Qj7AjF6aRtoaR5ATecWr5hCzup66iq0= Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 60094ACAF; Mon, 4 Jan 2021 12:51:28 +0000 (UTC) Date: Mon, 4 Jan 2021 13:51:22 +0100 From: Michal Hocko To: Liang Li Cc: Matthew Wilcox , Alexander Duyck , Mel Gorman , Andrew Morton , Andrea Arcangeli , Dan Williams , "Michael S. Tsirkin" , David Hildenbrand , Jason Wang , Dave Hansen , Liang Li , linux-mm@kvack.org, linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org Subject: Re: [RFC v2 PATCH 0/4] speed up page allocation for __GFP_ZERO Message-ID: <20210104125122.GD13207@dhcp22.suse.cz> References: <20201221162519.GA22504@open-light-1.localdomain> <20201222122312.GH874@casper.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 22-12-20 22:42:13, Liang Li wrote: > > > ===================================================== > > > QEMU use 4K pages, THP is off > > > round1 round2 round3 > > > w/o this patch: 23.5s 24.7s 24.6s > > > w/ this patch: 10.2s 10.3s 11.2s > > > > > > QEMU use 4K pages, THP is on > > > round1 round2 round3 > > > w/o this patch: 17.9s 14.8s 14.9s > > > w/ this patch: 1.9s 1.8s 1.9s > > > ===================================================== > > > > The cost of zeroing pages has to be paid somewhere. You've successfully > > moved it out of this path that you can measure. So now you've put it > > somewhere that you're not measuring. Why is this a win? > > Win or not depends on its effect. For our case, it solves the issue > that we faced, so it can be thought as a win for us. If others don't > have the issue we faced, the result will be different, maybe they will > be affected by the side effect of this feature. I think this is your > concern behind the question. right? I will try to do more tests and > provide more benchmark performance data. Yes, zeroying memory does have a noticeable overhead but we cannot simply allow tasks to spil over this overhead to all other users by default. So if anything this would need to be an opt-in feature configurable by administrator. -- Michal Hocko SUSE Labs