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 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 9E3ADC433E0 for ; Thu, 14 Jan 2021 16:16:50 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0F958239EB for ; Thu, 14 Jan 2021 16:16:49 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0F958239EB Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=bytedance.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 378656B00D4; Thu, 14 Jan 2021 11:16:49 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 328488D008E; Thu, 14 Jan 2021 11:16:49 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 23F286B00DF; Thu, 14 Jan 2021 11:16:49 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0185.hostedemail.com [216.40.44.185]) by kanga.kvack.org (Postfix) with ESMTP id 0FE426B00D4 for ; Thu, 14 Jan 2021 11:16:49 -0500 (EST) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id BC43C1809B389 for ; Thu, 14 Jan 2021 16:16:48 +0000 (UTC) X-FDA: 77704884096.26.lace04_240c75c27528 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin26.hostedemail.com (Postfix) with ESMTP id 6D6181800A671 for ; Thu, 14 Jan 2021 16:16:46 +0000 (UTC) X-HE-Tag: lace04_240c75c27528 X-Filterd-Recvd-Size: 5541 Received: from mail-pg1-f172.google.com (mail-pg1-f172.google.com [209.85.215.172]) by imf11.hostedemail.com (Postfix) with ESMTP for ; Thu, 14 Jan 2021 16:16:45 +0000 (UTC) Received: by mail-pg1-f172.google.com with SMTP id v19so4066005pgj.12 for ; Thu, 14 Jan 2021 08:16:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EdNTOqOvyf8Tea3ZmWu3U3/lQGFILtHgmE8Sp1YYSBw=; b=mPaB30g+aaNeYsC8ThEUmugQmr7YYF34vDTtDJQ5bSF2ariYpJUXrAKrWcKzQml1Ce BZHHntW620nED3kCQ+r1JnUoQDjP8ItVpFq91JYcbIbfIHkuHd6z6gZDnm16mK/FDifa CtkmsHnS1G8bT813sIqDMpSklmtUMYB8DJbbjdhLNs5shLsb+FOEPIOOxyb5HMTs5uYY 9U2gXhOL5uryQ8sV4z2+GTmCUCZ59gdl4kxCN5hlQxlZTfGTcfvr+L/8CODLM/cWx1Eh g2jQqNL7dGAkpZasBARQp0TME7jqU8q/qeU7R49Qv4DH/4AJhCVeDMw3iSSdCHI8/fY/ q0Zg== 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; bh=EdNTOqOvyf8Tea3ZmWu3U3/lQGFILtHgmE8Sp1YYSBw=; b=hwYDHEiPs54B1buYw5/tDe4MqNRMq1nMikLAkKme+MkDwrc3LWhyMTzdGhdzNFmNpl Pvrai+t2Q941KDI1P5RNAxrW6MLE5R1LsgARtrDxt0Roq/Mn+k/MEPlMT5OQKyoE83Li A7EuvqfFj6SJ21aWH43iA8BhP58nT5h9azFHD6w4R+Niv7ORV8dIvNpt+SbViZfq0mZ6 cIAx7Y0ma2mBFTa6oOo+ueex3nI180zoSjtCFm6pIo7cqokhMeZmgwTBGu6rrgrcWj15 3OVT6DV7E/TxZASH7L9g0/2oAiZmRa9cMq5S6OuD0YmfKd0HSLYEmgej1cBll/MaZqMK itbw== X-Gm-Message-State: AOAM531m810UiCBySLwIKpELl4S2YYDXgaXDwym7uNf+Ie/sX9bitgNw 6VNxr2XIkDkH9RHyyfpow1+5n42b3Xo5rCC4d/7nGg== X-Google-Smtp-Source: ABdhPJyak9V+7hTS5nAbw63BmX6DhXM6u6obe1PXWk3slHn4QmreKq+n9mbFRtV10UZWIMO1JV5pgg0xda97yeyfIV0= X-Received: by 2002:a63:50a:: with SMTP id 10mr8230385pgf.273.1610641004434; Thu, 14 Jan 2021 08:16:44 -0800 (PST) MIME-Version: 1.0 References: <20210114103515.12955-1-songmuchun@bytedance.com> <20210114103515.12955-4-songmuchun@bytedance.com> <20210114132036.GA27777@dhcp22.suse.cz> <20210114153814.GB27777@dhcp22.suse.cz> In-Reply-To: <20210114153814.GB27777@dhcp22.suse.cz> From: Muchun Song Date: Fri, 15 Jan 2021 00:16:04 +0800 Message-ID: Subject: Re: [External] Re: [PATCH v5 3/5] mm: hugetlb: fix a race between freeing and dissolving the page To: Michal Hocko Cc: Mike Kravetz , Andrew Morton , Naoya Horiguchi , Andi Kleen , Linux Memory Management List , LKML , linux- stable Content-Type: text/plain; charset="UTF-8" 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 Thu, Jan 14, 2021 at 11:38 PM Michal Hocko wrote: > > On Thu 14-01-21 21:47:36, Muchun Song wrote: > > On Thu, Jan 14, 2021 at 9:20 PM Michal Hocko wrote: > [...] > > > > @@ -1770,6 +1789,28 @@ int dissolve_free_huge_page(struct page *page) > > > > int nid = page_to_nid(head); > > > > if (h->free_huge_pages - h->resv_huge_pages == 0) > > > > goto out; > > > > + > > > > + /* > > > > + * We should make sure that the page is already on the free list > > > > + * when it is dissolved. > > > > + */ > > > > + if (unlikely(!PageHugeFreed(head))) { > > > > + spin_unlock(&hugetlb_lock); > > > > + > > > > + /* > > > > + * 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. > > > > + */ > > > > + while (PageHeadHuge(head) && !PageHugeFreed(head)) > > > > + cond_resched(); > > > > > > Sorry, I should have raised that when replying to the previous version > > > already but we have focused more on other things. Is there any special > > > reason that you didn't simply > > > if (!PageHugeFreed(head)) { > > > spin_unlock(&hugetlb_lock); > > > cond_resched(); > > > goto retry; > > > } > > > > > > This would be less code and a very slight advantage would be that the > > > waiter might get blocked on the spin lock while the concurrent freeing > > > is happening. But maybe you wanted to avoid exactly this contention? > > > Please put your thinking into the changelog. > > > > I want to avoid the lock contention. I will add this reason > > to the changelog. Thanks. > > Please also explain why it matters and whether an unintended contention > is a real problem. I have no idea about this, it is just my opinion. I will follow your suggestion. > -- > Michal Hocko > SUSE Labs