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 3E4BFC433E0 for ; Wed, 6 Jan 2021 16:08:32 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id BEF6B2312F for ; Wed, 6 Jan 2021 16:08:31 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BEF6B2312F 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 ED1446B0295; Wed, 6 Jan 2021 11:08:30 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E819E6B0296; Wed, 6 Jan 2021 11:08:30 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DBF586B0297; Wed, 6 Jan 2021 11:08:30 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0182.hostedemail.com [216.40.44.182]) by kanga.kvack.org (Postfix) with ESMTP id C601C6B0295 for ; Wed, 6 Jan 2021 11:08:30 -0500 (EST) Received: from smtpin23.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 8228D180AD806 for ; Wed, 6 Jan 2021 16:08:30 +0000 (UTC) X-FDA: 77675832780.23.park79_1e059a7274e2 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin23.hostedemail.com (Postfix) with ESMTP id 5E5CC37606 for ; Wed, 6 Jan 2021 16:08:30 +0000 (UTC) X-HE-Tag: park79_1e059a7274e2 X-Filterd-Recvd-Size: 3047 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf32.hostedemail.com (Postfix) with ESMTP for ; Wed, 6 Jan 2021 16:08: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=1609949308; 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=DqIGbcceYvDxkWsAJN0aQAT/RO0PdGdUprcpKKPoJYc=; b=FVZ5LPOFge/VBmJ/fHjfRqNhyng0Huq1LpfiWWD8JBDYkeUpBuOzuKdagFWmKgeB4wDJSF HOCiWnDetJMcdA9xdbaqvnv8ZyuuS79gUWWGdKyhKnSpEyBK8T/nl+UcqSKksTj18dDQ60 ucJYQeRrMLsVu65tHG7RQoeTGpgmM0M= Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 7A7FBAD8C; Wed, 6 Jan 2021 16:08:28 +0000 (UTC) Date: Wed, 6 Jan 2021 17:08:27 +0100 From: Michal Hocko To: Liang Li Cc: Alexander Duyck , Mel Gorman , Andrew Morton , Andrea Arcangeli , Dan Williams , "Michael S. Tsirkin" , David Hildenbrand , Jason Wang , Dave Hansen , Liang Li , Mike Kravetz , linux-mm@kvack.org, linux-kernel@vger.kernel.org, virtualization@lists.linux-foundation.org Subject: Re: [PATCH 3/6] hugetlb: add free page reporting support Message-ID: <20210106160827.GO13207@dhcp22.suse.cz> References: <20210106034918.GA1154@open-light-1.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210106034918.GA1154@open-light-1.localdomain> 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 22:49:21, Liang Li wrote: > hugetlb manages its page in hstate's free page list, not in buddy > system, this patch try to make it works for hugetlbfs. It canbe > used for memory overcommit in virtualization and hugetlb pre zero > out. David has layed down some more fundamental questions in the reply to the cover letter (btw. can you fix your scripts to send patches and make all the patches to be in reply to the cover letter please?). But I would like to point out that this changelog would need to change a lot as well. It doesn't explain really what, why and how. E.g. what would any guest gain by being able to report free huge pages? What would guarantee that the pool is replenished when there is a demand? Can this make the fault fail or it just takes more time to be satisfied? Why did you decide that the reporting infrastructure should be abused to do the zeroying? I do remember Alexander pushing back against that and so you should better have a very strong arguments to proceed that way. I am pretty sure there are more questions to come when more details are uncovered. -- Michal Hocko SUSE Labs