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=-15.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 381B1C433DB for ; Tue, 12 Jan 2021 08:33:41 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 9D5E522DD3 for ; Tue, 12 Jan 2021 08:33:40 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 9D5E522DD3 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 BADF98D0075; Tue, 12 Jan 2021 03:33:39 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B34878D0051; Tue, 12 Jan 2021 03:33:39 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A26198D0075; Tue, 12 Jan 2021 03:33:39 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0053.hostedemail.com [216.40.44.53]) by kanga.kvack.org (Postfix) with ESMTP id 896A28D0051 for ; Tue, 12 Jan 2021 03:33:39 -0500 (EST) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 3611D180AD802 for ; Tue, 12 Jan 2021 08:33:39 +0000 (UTC) X-FDA: 77696459358.24.page56_0308d1327514 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin24.hostedemail.com (Postfix) with ESMTP id 168E71A4A5 for ; Tue, 12 Jan 2021 08:33:39 +0000 (UTC) X-HE-Tag: page56_0308d1327514 X-Filterd-Recvd-Size: 3561 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf15.hostedemail.com (Postfix) with ESMTP for ; Tue, 12 Jan 2021 08:33:37 +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=1610440416; 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=tFyuOPvxyGNop7uNDLj50gfban0pju4pNlEfxYtxhP4=; b=uluWLvun6anFgHoBGFQfFga5gMQmABwrLQKy9vuQsoYzcnkJNsc4bJNo3uYTkW5YiyUWzu y3kIDb87TPls7fy9lsYeDbvtmgibb9QSNiyVk03j+AHbCKV6bkhcs3xbF0/U72/ulGJyrx HYzy+BlZL8ps+ZSertRXAMJgmveBuBQ= Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id A5D81ADC1; Tue, 12 Jan 2021 08:33:36 +0000 (UTC) Date: Tue, 12 Jan 2021 09:33:35 +0100 From: Michal Hocko To: Mike Kravetz Cc: Muchun Song , akpm@linux-foundation.org, n-horiguchi@ah.jp.nec.com, ak@linux.intel.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v3 4/6] mm: hugetlb: add return -EAGAIN for dissolve_free_huge_page Message-ID: <20210112083335.GH22493@dhcp22.suse.cz> References: <20210110124017.86750-1-songmuchun@bytedance.com> <20210110124017.86750-5-songmuchun@bytedance.com> 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 Mon 11-01-21 17:20:51, Mike Kravetz wrote: > On 1/10/21 4:40 AM, Muchun Song wrote: > > There is a race between dissolve_free_huge_page() and put_page(), > > and the race window is quite small. Theoretically, we should return > > -EBUSY when we encounter this race. In fact, we have a chance to > > successfully dissolve the page if we do a retry. Because the race > > window is quite small. If we seize this opportunity, it is an > > optimization for increasing the success rate of dissolving page. > > > > If we free a HugeTLB page from a non-task context, it is deferred > > through a workqueue. In this case, we need to flush the work. > > > > The dissolve_free_huge_page() can be called from memory hotplug, > > the caller aims to free the HugeTLB page to the buddy allocator > > so that the caller can unplug the page successfully. > > > > Signed-off-by: Muchun Song > > --- > > mm/hugetlb.c | 26 +++++++++++++++++++++----- > > 1 file changed, 21 insertions(+), 5 deletions(-) > > I am unsure about the need for this patch. The code is OK, there are no > issues with the code. > > As mentioned in the commit message, this is an optimization and could > potentially cause a memory offline operation to succeed instead of fail. > However, we are very unlikely to ever exercise this code. Adding an > optimization that is unlikely to be exercised is certainly questionable. > > Memory offline is the only code that could benefit from this optimization. > As someone with more memory offline user experience, what is your opinion > Michal? I am not a great fun of optimizations without any data to back them up. I do not see any sign this code has been actually tested and the condition triggered. Besides that I have requested to have an explanation of why blocking on the WQ is safe and that hasn't happened. -- Michal Hocko SUSE Labs