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=-10.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable 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 D5222C3526B for ; Sat, 5 Dec 2020 18:42:34 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id B4CE122EBF for ; Sat, 5 Dec 2020 18:42:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726629AbgLESmT (ORCPT ); Sat, 5 Dec 2020 13:42:19 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:34132 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726653AbgLERic (ORCPT ); Sat, 5 Dec 2020 12:38:32 -0500 Received: from mail-lj1-x242.google.com (mail-lj1-x242.google.com [IPv6:2a00:1450:4864:20::242]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A53A4C09425C for ; Sat, 5 Dec 2020 09:09:26 -0800 (PST) Received: by mail-lj1-x242.google.com with SMTP id a1so8921009ljq.3 for ; Sat, 05 Dec 2020 09:09:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/nONXOe+JWtgC2NEmkR8xcycTkJWCy3WRXYAibxk+2U=; b=yAzk/g0i/6/Y6AzhoKNkjYDk3qK4szrD6DsIQ4UoHDW1oA3d0TSHuu5PWZvw7Zsmlv 1dnq22xAK7TqogoAxD6fqNwYqONi097hVb9LoEARvuMt/0Hdoe+Et+w/PaHRsDWLYjyq 2HFuCynV7L5JahwqLLzju7RNQlxDwk+5z3oRFxN6EBtFtiid9xL2u27p45hrERqs8QJH C9NE1OMzdCnWWRlY75T8FanAYscof8A/ico/yDns8su9phtpAPbixulYBvCbbTEEde1q exfqh89UjkxEKfyw/cBlueCkcqxz1w1Np9sYMUzD7DNfFRUsHisFsxBQ9otWK3rjZQZk UzLA== 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=/nONXOe+JWtgC2NEmkR8xcycTkJWCy3WRXYAibxk+2U=; b=Rvz1R+rS/RWqTEXg+M6P3OfiHIdmBy74jF2eSG2RQCexi3YOFcPXaOS9EC5uePoZop LL5npXP/CJad7DCY+Q1NDNDFSx/WO5OdGIjPJugEFwA8/o2vHJxY/1LGqHTRGAPEzQWi dEIoL3DobfWaO5H6Vujit0oBC9zNLXjgIPpUVjMCmTvhoLEM7NUZUMK/BiKsFnUjN4QT V1hIFfFTblcPrQqdIRVKtle8V/Yt8/jFJWgFWhJgxl6ZtfwwqanWlg9mjbkPspbZ3nhB XclbR/1af9WLp5tSalbE6RWOEVZqnFj448VxUj7qd/LSKl94m/pLSDwTOp9/jcM1rgep wDrg== X-Gm-Message-State: AOAM531tOA5Bz3Kr+4PhqeQ+9k+Jqg8t+Y3WHb7xPBx9LT8E/T1ehXlA 0kMBHXhC2Q8ERWOANGgEUHjG2IjXBP0msMYLMYj74w== X-Google-Smtp-Source: ABdhPJxoqecW7LxgD0r1nAG22AfBGr3ZG5mFYrc/nZRyjVvcls3d0uOXjvm1Adw1hkBjXMOIspeSVTJhjTpxwyiPGp8= X-Received: by 2002:a05:651c:112e:: with SMTP id e14mr5724965ljo.388.1607188164947; Sat, 05 Dec 2020 09:09:24 -0800 (PST) MIME-Version: 1.0 References: <20201203152311.5272-1-carver4lio@163.com> <3d709122-0364-5bca-9247-3f212096b389@nvidia.com> In-Reply-To: <3d709122-0364-5bca-9247-3f212096b389@nvidia.com> From: Anders Roxell Date: Sat, 5 Dec 2020 18:09:14 +0100 Message-ID: Subject: Re: [PATCH] mm/memblock:use a more appropriate order calculation when free memblock pages To: Jon Hunter Cc: Marek Szyprowski , Qian Cai , carver4lio@163.com, rppt@kernel.org, Andrew Morton , Linux-MM , Linux Kernel Mailing List , Hailong Liu , Stephen Rothwell , Linux Next Mailing List , Bartlomiej Zolnierkiewicz , linux-tegra Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 4 Dec 2020 at 18:44, Jon Hunter wrote: > > > On 04/12/2020 16:07, Marek Szyprowski wrote: > > Hi All, > > > > On 04.12.2020 14:42, Qian Cai wrote: > >> On Thu, 2020-12-03 at 23:23 +0800, carver4lio@163.com wrote: > >>> From: Hailong Liu > >>> > >>> When system in the booting stage, pages span from [start, end] of a memblock > >>> are freed to buddy in a order as large as possible (less than MAX_ORDER) at > >>> first, then decrease gradually to a proper order(less than end) in a loop. > >>> > >>> However, *min(MAX_ORDER - 1UL, __ffs(start))* can not get the largest order > >>> in some cases. > >>> Instead, *__ffs(end - start)* may be more appropriate and meaningful. > >>> > >>> Signed-off-by: Hailong Liu > >> Reverting this commit on the top of today's linux-next fixed boot crashes on > >> multiple NUMA systems. > > > > I confirm. Reverting commit 4df001639c84 ("mm/memblock: use a more > > appropriate order calculation when free memblock pages") on top of linux > > next-20201204 fixed booting of my ARM32bit test systems. > > > FWIW, I also confirm that this is causing several 32-bit Tegra platforms > to crash on boot and reverting this fixes the problem. I had the same experience on an arm64 system. Cheers, Anders