Received: by 2002:a05:6359:c8b:b0:c7:702f:21d4 with SMTP id go11csp2287062rwb; Mon, 19 Sep 2022 02:48:39 -0700 (PDT) X-Google-Smtp-Source: AMsMyM5cs7yuu6VRuMn9RkB4a63I1cuEluX7KC7bwYZffjGllmfqhM50+7TZ3xE9FF9GwVsuc2FP X-Received: by 2002:aa7:90ce:0:b0:547:1cf9:40e6 with SMTP id k14-20020aa790ce000000b005471cf940e6mr17672623pfk.11.1663580918747; Mon, 19 Sep 2022 02:48:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1663580918; cv=none; d=google.com; s=arc-20160816; b=B7kzB2x2dsEIh5ORtnl7atYrmVUX9mfigb74znL6aSQnLI/O+mL7XL1z1imXomPaDJ W6rdO7GNBaOrPPzyEyd74mfg1PDs4MTsz/nfwcZSu8Ql6H91iB3Br/SJFq9fP/+ZXbu2 CvuUxEhHsqDLiPL6Mh9uH4IWWGtnNmhxtaOnV1NsiszqXwewHrCzRHFZR6w3WhL5OVGn toiGnp4gSae3IjRwNYoGVKsKB/32LCv98BjR17EJjQuGwxj2YoG2S+Tj4XC3LlNnp7RG irpUYf/QQOZ5GqVeFAYvcGgGrnD+whvyqfnRKdNbiYQyBsalBWDK0RGuTpjUyC5pwnoT Perw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=71tJeFVKAFJ3SyXs+rHfkSElvEqevvrgispgsbeaJQk=; b=Dv93XY/WhmpFqBYymw6j3QHLZtjYBQPkUclgxXmMhz3MLBmShm2o+nWjVoEH5JbJas XFB1FUTTC2O1NlOtU+ZD0I+My3VJaWMgYxwWhlEDcoMTitVVzYZLUZtJxd1dsRRNWTpG Dd5ylWRz8yFyerrTMIZJw1qLtw8fol5Bz9hC+3NnIol6/ajZgbMGdbqQz4HmLFN238be tVTq1IrR69g8Z8JutTZjzKQ+OK6O2/Cj02T79nBygY07abP15kSCQNZoeOMCNlo/L4hW DvfgN9gSQAOxS9PVZzVwjj4wEntrx50+hmQrGeCwi0eY02P7tZhasNOnTmoxxQWSvSM5 kZZA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@amarulasolutions.com header.s=google header.b=oKnCZapF; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=amarulasolutions.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id rm8-20020a17090b3ec800b001fabad2f85asi11829241pjb.120.2022.09.19.02.48.28; Mon, 19 Sep 2022 02:48:38 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@amarulasolutions.com header.s=google header.b=oKnCZapF; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=amarulasolutions.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229798AbiISJSJ (ORCPT + 99 others); Mon, 19 Sep 2022 05:18:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57618 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229613AbiISJSH (ORCPT ); Mon, 19 Sep 2022 05:18:07 -0400 Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4D46D1F627 for ; Mon, 19 Sep 2022 02:18:06 -0700 (PDT) Received: by mail-ej1-x62e.google.com with SMTP id dv25so62909314ejb.12 for ; Mon, 19 Sep 2022 02:18:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amarulasolutions.com; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=71tJeFVKAFJ3SyXs+rHfkSElvEqevvrgispgsbeaJQk=; b=oKnCZapF9aLxY830pJtvgk/IqGq1UKs9KlKo2+7C/xa1SuE7wtYq0h07vI3SAe+5iv sZp9QpRF/wCHDF88iDwOzJPZtPm116YC+uIMZ2ormEb9EWPLjfuP334xZbz6uSvBSjsf pSarGpzCUKkYESOBiTTlxBerflIEXIXz0oq7Q= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=71tJeFVKAFJ3SyXs+rHfkSElvEqevvrgispgsbeaJQk=; b=UtwOEAbcMAJmPHX1Pp9U7sBLdhZ6DlJ2Clvrz8D0xZOfiHmvYDEUFoRtwOmiFqvzYc pnKmHKwuOEm6/hf3HxhNun6l25rlCtovcRPuoPGdLnvWBlu0nhGr3R58/PjEgIget8+0 nH6vL8vdh0gCWwCzKEEi+f1D0gmaxQG1iPWl1WK/9T2mLlkB8tcIOwaFz8XVhOzJTlUs qjr53vzi31TKgfLDDlLa+1P0oOCOiQ5JHmdnhDqUfvIm1aZM8lzTfVYG1JVaisw/oZmg 6N0bTYt13wxHCZk+VWc43kL7zaK3P27plgJUjjBtVxild0VbKGTPB9PoWE6l57lC2tJf rZjQ== X-Gm-Message-State: ACrzQf3j2vIJYS0a+mWBQJYhOTVwuMBbKZNsrnEEG/CmVZTqGO51P/kq ZYsjEoIrfF+B7OVNCetvrziYw87VDtCt0PUzCc+WPQ== X-Received: by 2002:a17:907:6087:b0:77a:51e9:8e86 with SMTP id ht7-20020a170907608700b0077a51e98e86mr12197341ejc.31.1663579084797; Mon, 19 Sep 2022 02:18:04 -0700 (PDT) MIME-Version: 1.0 References: <826cd775-14d2-12ae-2e96-cf0766aa1502@redhat.com> In-Reply-To: <826cd775-14d2-12ae-2e96-cf0766aa1502@redhat.com> From: Michael Nazzareno Trimarchi Date: Mon, 19 Sep 2022 11:17:53 +0200 Message-ID: Subject: Re: Correlation CMA size and FORCE_MAX_ZONEORDER To: David Hildenbrand Cc: Mike Rapoport , LKML , Andrew Morton Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi David On Mon, Sep 19, 2022 at 10:38 AM David Hildenbrand wrote: > > On 15.09.22 23:36, Michael Nazzareno Trimarchi wrote: > > Hi all > > Hi, > > > > > Working on a small device with 128MB of memory and using imx_v6_v7 > > defconfig I found that CMA_SIZE_MBYTES, CMA_SIZE_PERCENTAGE > > are not respected. The calculation done does not allow the requested > > size. I think that this should be somehow documented and described but > > I did not > > find the documentation. Does it work this way? > > > > With CMA_SIZE of 8MB I need to have FORCE_MAX_ZONEORDER=12 if I have > > the default FORCE_MAX_ZONEORDER=14 the min size is 32Mb > > The underlying constraint is that CMA regions require a certain minimum > alignment+size. They cannot be arbitrarily in size. > > CMA_MIN_ALIGNMENT_BYTES expresses that, and corresponds in upstream > kernels to the size of a single pageblock. > > In previous kernels, it used to be the size of the largest buddy > allocation granularity (derived from MAX_ORDER, derived from > FORCE_MAX_ZONEORDER). > > On upstream kernels, the FORCE_MAX_ZONEORDER constraint should no longer > apply. On most archs, the minimum alignment+size should be 2 MiB > (x86-64, aarch64 with 4k base pages) -- the size of a single pageblock. > > So far the theory. Are you still running into this limitation on > upstream kernels? > I can run 6-rc2 on my board. I test again but according to it, if I put 4M as CMA in cma=4M in boot parameters, the result is 32Mb of CMA. Apart of that seems that process lime tiny membench can not even start to mblock memory Michael > -- > Thanks, > > David / dhildenb > -- Michael Nazzareno Trimarchi Co-Founder & Chief Executive Officer M. +39 347 913 2170 michael@amarulasolutions.com __________________________________ Amarula Solutions BV Joop Geesinkweg 125, 1114 AB, Amsterdam, NL T. +31 (0)85 111 9172 info@amarulasolutions.com www.amarulasolutions.com