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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id AD2DAC433EF for ; Thu, 17 Mar 2022 03:49:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DF76F6B0071; Wed, 16 Mar 2022 23:49:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id DA7CE8D0002; Wed, 16 Mar 2022 23:49:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C48828D0001; Wed, 16 Mar 2022 23:49:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.28]) by kanga.kvack.org (Postfix) with ESMTP id B18606B0071 for ; Wed, 16 Mar 2022 23:49:29 -0400 (EDT) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 86543231E3 for ; Thu, 17 Mar 2022 03:49:29 +0000 (UTC) X-FDA: 79252498458.01.EAA6288 Received: from mail-ot1-f50.google.com (mail-ot1-f50.google.com [209.85.210.50]) by imf03.hostedemail.com (Postfix) with ESMTP id 6F34D2001E for ; Thu, 17 Mar 2022 03:49:28 +0000 (UTC) Received: by mail-ot1-f50.google.com with SMTP id v25-20020a05683024b900b005b2463a41faso2721196ots.10 for ; Wed, 16 Mar 2022 20:49:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bzUnjGDyXu7q9v4BjGZ982U1CVW2XxSBT1y4mEjRJv0=; b=lPqokLZqsCxHE1yHiPzSj38FzKqk0WtvURGh1j2mZGRinC9mx6Br+yZUHETj9FU6EU f5tfU/cotSH2mNNo1cog37Kg+5PbkDh6hAHoMDvwCFhLDCvNhsJqjiLkxpjgqpsyR1ks /heSfFFcjoT9Y5tkJordX492YJE6kZpUJABWooPMA6LxTsOPWjlVkbmj1ZR+v8QM+pu9 vKqGMc6gq6v/fbNyRVGlTr2bUiZWyz6PvvVeChYmLUVPBnDaAtbM/yknwctgsNRP1cwO i0c72KK//O2pAyxiwoCt19dCIUgBxxIeJ8U3pkcxdQiQPhhzBxmJinC1RBLqbT8Ndvak BoaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bzUnjGDyXu7q9v4BjGZ982U1CVW2XxSBT1y4mEjRJv0=; b=suHePuwmFTbCbJhtXyEr60M8xGNlpxwLqXwZ2q5xmu3/TsI+OqsfVJwHHe7kju9INp KbueU8lMhSKgWxyNdqP8u54OYZOnvjssbPF1sG8tEqZ1I1CNRipl3o2i8qK4V4+VkXmx feRujCYpqxROzNkeK2pgIA8X+4GvN58rxRB554PYp4Hr6QTFfflI9sfFb23N9okBujSY Sa7rDU4xGIBBGCqXAo68lMKtSPcPSZZUqyNuRCNQ4jERu1JRDvCqCgRQszNMXZ3q+Yzi rbIZyVmpLwgMUvVw0/zNJJZsR9jOC/G30mcoLNBIr2IdJRG732GB478LIWnhb+lKGsbA 0Bjg== X-Gm-Message-State: AOAM531qslU4RHw1N2vPyoPLTTlvpdlPOFJ702zn4bQjCf64rp4QKocN fHFUuZrAFRV9IsfFpKw6LbT/ed3LAPedgpxbsI8= X-Google-Smtp-Source: ABdhPJyFB4RAag2Fam31j7R7qBMFYRNd6SNZ1PP5uYDwvdKBwhy3oxZu7RngKvwR2SO67orM0Owagt8qYRoNNH4+YAk= X-Received: by 2002:a05:6830:1394:b0:5af:6776:ea37 with SMTP id d20-20020a056830139400b005af6776ea37mr987418otq.80.1647488968237; Wed, 16 Mar 2022 20:49:28 -0700 (PDT) MIME-Version: 1.0 References: <20220315144521.3810298-1-aisheng.dong@nxp.com> <20220315144521.3810298-2-aisheng.dong@nxp.com> <20220315155837.2dcef6eb226ad74e37ca31ca@linux-foundation.org> <20220316140904.513fe0e8180b4e3fcad24e3b@linux-foundation.org> In-Reply-To: <20220316140904.513fe0e8180b4e3fcad24e3b@linux-foundation.org> From: Dong Aisheng Date: Thu, 17 Mar 2022 11:49:16 +0800 Message-ID: Subject: Re: [PATCH v3 1/2] mm: cma: fix allocation may fail sometimes To: Andrew Morton Cc: Dong Aisheng , linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, shawnguo@kernel.org, linux-imx@nxp.com, m.szyprowski@samsung.com, lecopzer.chen@mediatek.com, david@redhat.com, vbabka@suse.cz, stable@vger.kernel.org, shijie.qin@nxp.com Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 6F34D2001E X-Rspam-User: Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=lPqokLZq; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf03.hostedemail.com: domain of dongas86@gmail.com designates 209.85.210.50 as permitted sender) smtp.mailfrom=dongas86@gmail.com X-Stat-Signature: 11qxicapkymagzzs3t1o7okwdp7zs8gd X-Rspamd-Server: rspam04 X-HE-Tag: 1647488968-430917 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, Mar 17, 2022 at 5:09 AM Andrew Morton wrote: > > On Wed, 16 Mar 2022 11:41:37 +0800 Dong Aisheng wrote: > > > On Wed, Mar 16, 2022 at 6:58 AM Andrew Morton wrote: > > > > > > On Tue, 15 Mar 2022 22:45:20 +0800 Dong Aisheng wrote: > > > > > > > --- a/mm/cma.c > > > > +++ b/mm/cma.c > > > > > > > > ... > > > > > > > > @@ -457,6 +458,16 @@ struct page *cma_alloc(struct cma *cma, unsigned long count, > > > > offset); > > > > if (bitmap_no >= bitmap_maxno) { > > > > spin_unlock_irq(&cma->lock); > > > > + pr_debug("%s(): alloc fail, retry loop %d\n", __func__, loop++); > > > > + /* > > > > + * rescan as others may finish the memory migration > > > > + * and quit if no available CMA memory found finally > > > > + */ > > > > + if (start) { > > > > + schedule(); > > > > + start = 0; > > > > + continue; > > > > + } > > > > break; > > > > > > The schedule() is problematic. For a start, we'd normally use > > > cond_resched() here, so we avoid calling the more expensive schedule() > > > if we know it won't perform any action. > > > > > > But cond_resched() is problematic if this thread has realtime > > > scheduling policy and the process we're waiting on does not. One way > > > to address that is to use an unconditional msleep(1), but that's still > > > just a hack. > > > > > > > I think we can simply drop schedule() here during the second round of retry > > as the estimated delay may not be really needed. > > That will simply cause a tight loop, so I'm obviously not understanding > the proposal. > IIUC the original code is already a tight loop, isn't it? You could also see my observation, thousands of retries, in patch 2. The logic in this patch is just retry the original loop in case in case there's a false possive error return. Or you mean infinite loop? The loop will break out when meet an non EBUSY error in alloc_contig_range(). BTW, the tight loop situation could be improved a lot by my patch 2. And after Zi Yan's patchset [1] got merged, the situation could be further improved by retring in pageblock step. 1. [v7,0/5] Use pageblock_order for cma and alloc_contig_range alignment. - Patchwork (kernel.org) So generally i wonder it seems still better than simply revert. Please fix me if i still missed something. Regards Aisheng