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=-0.8 required=3.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,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 2DFAEC433EF for ; Tue, 7 Sep 2021 08:50:21 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 6E375610E9 for ; Tue, 7 Sep 2021 08:50:20 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 6E375610E9 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=sina.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 073D06B0071; Tue, 7 Sep 2021 04:50:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 02358900002; Tue, 7 Sep 2021 04:50:19 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E7BD66B0073; Tue, 7 Sep 2021 04:50:19 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0188.hostedemail.com [216.40.44.188]) by kanga.kvack.org (Postfix) with ESMTP id D4A426B0071 for ; Tue, 7 Sep 2021 04:50:19 -0400 (EDT) Received: from smtpin34.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 81FC629DE3 for ; Tue, 7 Sep 2021 08:50:19 +0000 (UTC) X-FDA: 78560155758.34.67494B3 Received: from r3-24.sinamail.sina.com.cn (r3-24.sinamail.sina.com.cn [202.108.3.24]) by imf20.hostedemail.com (Postfix) with SMTP id 4071FD0000AF for ; Tue, 7 Sep 2021 08:50:15 +0000 (UTC) Received: from unknown (HELO localhost.localdomain)([123.115.166.15]) by sina.com (172.16.97.23) with ESMTP id 613727C2000254E6; Tue, 7 Sep 2021 16:50:13 +0800 (CST) X-Sender: hdanton@sina.com X-Auth-ID: hdanton@sina.com X-SMAIL-MID: 22378654919706 From: Hillf Danton To: Vlastimil Babka Cc: Mike Kravetz , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Michal Hocko Subject: Re: [PATCH RESEND 0/8] hugetlb: add demote/split page functionality Date: Tue, 7 Sep 2021 16:50:01 +0800 Message-Id: <20210907085001.3773-1-hdanton@sina.com> In-Reply-To: <597a7731-3692-01b9-9e71-ba265246cc1a@suse.cz> References: <20210816224953.157796-1-mike.kravetz@oracle.com> <20210816162749.22b921a61156a091f3e1d14d@linux-foundation.org> <20210816184611.07b97f4c26b83090f5d48fab@linux-foundation.org> <10d86c18-f0cf-395f-4209-17ac71b9fc03@oracle.com> <2d826470-d345-0196-1359-b79ed08dfc66@oracle.com> <02a1a50f-4e7c-4eb7-519c-35b26ec2c6af@oracle.com> MIME-Version: 1.0 Authentication-Results: imf20.hostedemail.com; dkim=none; spf=pass (imf20.hostedemail.com: domain of hdanton@sina.com designates 202.108.3.24 as permitted sender) smtp.mailfrom=hdanton@sina.com; dmarc=none X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: 4071FD0000AF X-Stat-Signature: pewjg3z656nmse3yu7pi7wbzuoohtrrm X-HE-Tag: 1631004615-800847 Content-Transfer-Encoding: quoted-printable X-Bogosity: Ham, tests=bogofilter, spamicity=0.000003, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, 6 Sep 2021 16:40:28 +0200 Vlastimil Babka wrote: >On 9/2/21 20:17, Mike Kravetz wrote: >>=20 >> Here is some very high level information from a long stall that was >> interrupted. This was an order 9 allocation from alloc_buddy_huge_pag= e(). >>=20 >> 55269.530564] __alloc_pages_slowpath: jiffies 47329325 tries 609673 cp= u_tries 1 node 0 FAIL >> [55269.539893] r_tries 25 c_tries 609647 reclaim 47325161 = compact 607 =20 >>=20 >> Yes, in __alloc_pages_slowpath for 47329325 jiffies before being inter= rupted. >> should_reclaim_retry returned true 25 times and should_compact_retry r= eturned >> true 609647 times. >> Almost all time (47325161 jiffies) spent in __alloc_pages_direct_recla= im, and >> 607 jiffies spent in __alloc_pages_direct_compact. >>=20 >> Looks like both >> reclaim retries > MAX_RECLAIM_RETRIES >> and >> compaction retries > MAX_COMPACT_RETRIES >>=20 >Yeah AFAICS that's only possible with the scenario I suspected. I guess >we should put a limit on compact retries (maybe some multiple of >MAX_COMPACT_RETRIES) even if it thinks that reclaim could help, while >clearly it doesn't (i.e. because somebody else is stealing the page like >in your test case). And/or clamp reclaim retries for costly orders reclaim retries =3D MAX_RECLAIM_RETRIES - order; to pull down the chance for stall as low as possible.