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=-3.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,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 14B52C352AA for ; Wed, 2 Oct 2019 00:14:28 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id BA1B42070B for ; Wed, 2 Oct 2019 00:14:27 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="nJtPZChL" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BA1B42070B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 528E08E0009; Tue, 1 Oct 2019 20:14:27 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4B2C08E0001; Tue, 1 Oct 2019 20:14:27 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 35BE38E0009; Tue, 1 Oct 2019 20:14:27 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0029.hostedemail.com [216.40.44.29]) by kanga.kvack.org (Postfix) with ESMTP id 0A8668E0001 for ; Tue, 1 Oct 2019 20:14:27 -0400 (EDT) Received: from smtpin23.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with SMTP id 7AD76181AC9AE for ; Wed, 2 Oct 2019 00:14:26 +0000 (UTC) X-FDA: 75996922932.23.run22_26b56b306f84c X-HE-Tag: run22_26b56b306f84c X-Filterd-Recvd-Size: 8507 Received: from mail-io1-f66.google.com (mail-io1-f66.google.com [209.85.166.66]) by imf24.hostedemail.com (Postfix) with ESMTP for ; Wed, 2 Oct 2019 00:14:25 +0000 (UTC) Received: by mail-io1-f66.google.com with SMTP id c25so52704123iot.12 for ; Tue, 01 Oct 2019 17:14:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Qp6mpPjoJw8IpL230TwztYNGcdXtc2wRumjJPrYIsQE=; b=nJtPZChLaez2QyIvdw5xpQM+gY+4nNfutZP/DX1GosRihN1p8Y/jzvzU5+zZVVXLDq DNW5rNxAEWMfY4DML2WBa4k8L6N9BKjZt+S1WhSwJylMRWekm8bQGBEDcBvcSstJLeH7 osBNQPoC6vhf9EY6DvGZUS8bjPCLVbggq0vpLSG6o0qgZ68mHanhcK7N3A/k0zMXrBbT Myz3NcGtILKbjxYen8N4nInaRBIm801lXbpfCzyfiuoGv9mi3cSKUjp9iAirGweypF7I T5mChO7ltGRoxOnD6pn9vRPircx8cSspNsbQ9S+cDzRYkEkb4WMfK2l7wEZANDZnvpgU 4hTA== 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=Qp6mpPjoJw8IpL230TwztYNGcdXtc2wRumjJPrYIsQE=; b=LZPAriCovFeYglALLelJcOuVGGFCkD3oLJ5OtKMqGJm8717mfmSZ6S90SXkOhxu0qr 5zyKYmGo6H/tPZCg/zcchhDD8/ztdw8LsuVQ8oqiTuxT6Atca5BAI5bRnflBaNSBkUN3 eOMGabPi15s/FfOm2WKasVRgcSbUVmjVVL2NiHs0iwQGCaFOI3FAAdcXx56tI+JRxMU1 5Qj0H+LXSiBRoagRMI+Wk5/c/RWrEgoe3c33vX6W/Jgrvdg3B08xoF/epPaBQ47Gi233 jOmoeoIFy3o9F8htBQQGQ+eEVtNoqYvjw1m8DKD/nOsuNLKHbYxILbBFd7jcXQ1Slg2v F/vg== X-Gm-Message-State: APjAAAUlVUjYkhvGBnhWSvanF6U4t8VTcw/Wfj/cKmjBj6bBzvTdhFHn l2U4nDUGa4NtXHPDuJtPQMjg8DwHuEXH1ugOZLA= X-Google-Smtp-Source: APXvYqw1icrX5CgHqYJTBX6lKVXwK6z5wdputtkAh6YFSqMaOhm8xmij6KJaNr2N6b3kx+nme5PxuCv6WXWh+UvZaMU= X-Received: by 2002:a92:3314:: with SMTP id a20mr890351ilf.276.1569975265009; Tue, 01 Oct 2019 17:14:25 -0700 (PDT) MIME-Version: 1.0 References: <1548057848-15136-1-git-send-email-rppt@linux.ibm.com> <20190926160433.GD32311@linux.ibm.com> <20190928073331.GA5269@linux.ibm.com> In-Reply-To: From: Adam Ford Date: Tue, 1 Oct 2019 19:14:13 -0500 Message-ID: Subject: Re: [PATCH v2 00/21] Refine memblock API To: Mike Rapoport Cc: Fabio Estevam , Rich Felker , linux-ia64@vger.kernel.org, Petr Mladek , linux-sh@vger.kernel.org, Catalin Marinas , Heiko Carstens , Linux Kernel Mailing List , Max Filippov , Guo Ren , Michael Ellerman , sparclinux@vger.kernel.org, Christoph Hellwig , linux-s390@vger.kernel.org, linux-c6x-dev@linux-c6x.org, Yoshinori Sato , Richard Weinberger , x86@kernel.org, Russell King , kasan-dev , Geert Uytterhoeven , Mark Salter , Dennis Zhou , Matt Turner , linux-snps-arc@lists.infradead.org, uclinux-h8-devel@lists.sourceforge.jp, devicetree , linux-xtensa@linux-xtensa.org, linux-um@lists.infradead.org, The etnaviv authors , linux-m68k@lists.linux-m68k.org, Rob Herring , Greentime Hu , xen-devel@lists.xenproject.org, Stafford Horne , Guan Xuetao , arm-soc , Michal Simek , Tony Luck , Linux Memory Management List , Greg Kroah-Hartman , USB list , linux-mips@vger.kernel.org, Paul Burton , Vineet Gupta , linux-alpha@vger.kernel.org, Andrew Morton , linuxppc-dev@lists.ozlabs.org, "David S. Miller" , openrisc@lists.librecores.org, Chris Healy 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 Sun, Sep 29, 2019 at 8:33 AM Adam Ford wrote: > > I am attaching two logs. I now the mailing lists will be unhappy, but > don't want to try and spam a bunch of log through the mailing liast. > The two logs show the differences between the working and non-working > imx6q 3D accelerator when trying to run a simple glmark2-es2-drm demo. > > The only change between them is the 2 line code change you suggested. > > In both cases, I have cma=128M set in my bootargs. Historically this > has been sufficient, but cma=256M has not made a difference. > Mike any suggestions on how to move forward? I was hoping to get the fixes tested and pushed before 5.4 is released if at all possible > adam > > On Sat, Sep 28, 2019 at 2:33 AM Mike Rapoport wrote: > > > > On Thu, Sep 26, 2019 at 02:35:53PM -0500, Adam Ford wrote: > > > On Thu, Sep 26, 2019 at 11:04 AM Mike Rapoport wrote: > > > > > > > > Hi, > > > > > > > > On Thu, Sep 26, 2019 at 08:09:52AM -0500, Adam Ford wrote: > > > > > On Wed, Sep 25, 2019 at 10:17 AM Fabio Estevam wrote: > > > > > > > > > > > > On Wed, Sep 25, 2019 at 9:17 AM Adam Ford wrote: > > > > > > > > > > > > > I tried cma=256M and noticed the cma dump at the beginning didn't > > > > > > > change. Do we need to setup a reserved-memory node like > > > > > > > imx6ul-ccimx6ulsom.dtsi did? > > > > > > > > > > > > I don't think so. > > > > > > > > > > > > Were you able to identify what was the exact commit that caused such regression? > > > > > > > > > > I was able to narrow it down the 92d12f9544b7 ("memblock: refactor > > > > > internal allocation functions") that caused the regression with > > > > > Etnaviv. > > > > > > > > > > > > Can you please test with this change: > > > > > > > > > > That appears to have fixed my issue. I am not sure what the impact > > > is, but is this a safe option? > > > > It's not really a fix, I just wanted to see how exactly 92d12f9544b7 ("memblock: > > refactor internal allocation functions") broke your setup. > > > > Can you share the dts you are using and the full kernel log? > > > > > adam > > > > > > > diff --git a/mm/memblock.c b/mm/memblock.c > > > > index 7d4f61a..1f5a0eb 100644 > > > > --- a/mm/memblock.c > > > > +++ b/mm/memblock.c > > > > @@ -1356,9 +1356,6 @@ static phys_addr_t __init memblock_alloc_range_nid(phys_addr_t size, > > > > align = SMP_CACHE_BYTES; > > > > } > > > > > > > > - if (end > memblock.current_limit) > > > > - end = memblock.current_limit; > > > > - > > > > again: > > > > found = memblock_find_in_range_node(size, align, start, end, nid, > > > > flags); > > > > > > > > > I also noticed that if I create a reserved memory node as was done one > > > > > imx6ul-ccimx6ulsom.dtsi the 3D seems to work again, but without it, I > > > > > was getting errors regardless of the 'cma=256M' or not. > > > > > I don't have a problem using the reserved memory, but I guess I am not > > > > > sure what the amount should be. I know for the video decoding 1080p, > > > > > I have historically used cma=128M, but with the 3D also needing some > > > > > memory allocation, is that enough or should I use 256M? > > > > > > > > > > adam > > > > > > > > -- > > > > Sincerely yours, > > > > Mike. > > > > > > > > -- > > Sincerely yours, > > Mike. > >