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 12B4FC27C53 for ; Wed, 12 Jun 2024 21:37:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5C8716B0083; Wed, 12 Jun 2024 17:37:30 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 578DD6B008C; Wed, 12 Jun 2024 17:37:30 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 419B46B0092; Wed, 12 Jun 2024 17:37:30 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 245D66B0083 for ; Wed, 12 Jun 2024 17:37:30 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 95441160430 for ; Wed, 12 Jun 2024 21:37:29 +0000 (UTC) X-FDA: 82223548218.19.EE623E4 Received: from mail-vs1-f43.google.com (mail-vs1-f43.google.com [209.85.217.43]) by imf17.hostedemail.com (Postfix) with ESMTP id DB37F40004 for ; Wed, 12 Jun 2024 21:37:27 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=none; spf=pass (imf17.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.217.43 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=kernel.org (policy=none) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1718228247; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=iGrQ4kC0usDlo6X7rb0FFn4z1I4iV8UOfsxmWyJU8T8=; b=g1t4cMMi2Xc68o/K5pkayh2aPACVYZ8vBUhuJ9KNk55wd4GjCTYfhv61QbBkmF/Vifa+ya 7YeXFrCUhJxv2dt5QMCNumA9wfazwZRv0MdOVCRuYpbVTpd041Ae1LOu92mTD2n9qhFeau SNtB5dV06Me3BYOqXbPr1rZlmoAkjF4= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=none; spf=pass (imf17.hostedemail.com: domain of 21cnbao@gmail.com designates 209.85.217.43 as permitted sender) smtp.mailfrom=21cnbao@gmail.com; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=kernel.org (policy=none) ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1718228247; a=rsa-sha256; cv=none; b=h4k49OF0hq7OG3S7OO4hafm4GsPN5+A0a9xdoAbLRcpaAQdPW+AIxsQAmL9EP2ALNpyxGs 2oewCSgty380iElXP50ArHQ2uw+Yl9aviktsynBVjK/KHvto0CazGG0Pka+mE51qDIE54e vADFgBaJDegaOGQtEGr8d874xvMMwEU= Received: by mail-vs1-f43.google.com with SMTP id ada2fe7eead31-48da4aaaf8aso1315137.2 for ; Wed, 12 Jun 2024 14:37:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1718228247; x=1718833047; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=iGrQ4kC0usDlo6X7rb0FFn4z1I4iV8UOfsxmWyJU8T8=; b=iv47I03GXkeQg8QDyQnHhYZ9voY5nOUkJ7nnOk8oCLh6rEUMYjUwjiCAzIHL92KoZt q5iWZCM4tzKcbGL1XfwdQ6Zw5iWFBEbFzUHSRcuGalKYevn2S7CBNDhbzYTftRwKSOMf b5qfXTRTqVvD3W5SejQ7vFzLcGu5mLe8U8h/S6nqLwh0ckFRiZTcLc9C3VJTnholi2bF kMPgvnrOlRJ91HdV9MfN6cuM28RnmBMUR8xnjV/GnC3giIC4GbJ8EckFf7UMcGg1BfBx fatjt9X8FeaQ8wLBm1M4SaSFfTcS1Lv9H0pxdZo8UfphDgDrHYmr7YLMgAX5X1D6WVEU H/VQ== X-Forwarded-Encrypted: i=1; AJvYcCVyaeIGqVGd8JSiSBQlTDU4cbpZgQDVvN4R5LJKLvbo2XE1rY94sIGa7XEnmJd4pKWgCSeQTGlEmrV0CaBN1Iyvjzc= X-Gm-Message-State: AOJu0Yzad3iep4wGMAwZGpV936bZGPaj852k+cKiS99cfqIIm3XGep2M vE58GYKnYMwZCL+eADfqu8KyRIGDzglDKuHchnM5DP6Mb/Wal2x9XPN1OJgvJQFzF5c3xT6cCnX YVfUNOU7TCY0q3/iFVo4AbUgOGTU= X-Google-Smtp-Source: AGHT+IFxF8EN06J17xFY/m06JGL5/Bofq4OOHKPvS2e7I791mJG11bjTcP4Zr47YKFd5X7pKAZ20ZqNeu7FQRBIxKg8= X-Received: by 2002:a05:6102:4646:b0:48c:454f:e7ea with SMTP id ada2fe7eead31-48d91e67d3cmr3414916137.29.1718228246725; Wed, 12 Jun 2024 14:37:26 -0700 (PDT) MIME-Version: 1.0 References: <20240612081216.1319089-1-zhai.he@nxp.com> <20240612114748.bf5983b50634f23d674bc749@linux-foundation.org> In-Reply-To: <20240612114748.bf5983b50634f23d674bc749@linux-foundation.org> From: Barry Song Date: Thu, 13 Jun 2024 09:37:15 +1200 Message-ID: Subject: Re: [PATCH v2] Supports to use the default CMA when the device-specified CMA memory is not enough. To: Andrew Morton Cc: "zhai.he" , sboyd@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org, zhipeng.wang_1@nxp.com, jindong.yue@nxp.com, Christoph Hellwig Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: DB37F40004 X-Stat-Signature: ta7hj4ajbieuez5o7ukgqxkrpm5nxp4e X-HE-Tag: 1718228247-381755 X-HE-Meta: U2FsdGVkX1/LNOKxzwK2v4f6aCl4SkavuNOG7Ewlv6k8WhA/e3ffdG2chheZH9HLci4nD3SaC2kfGfTO1NzDTszGK5sjHdaqVzdc15ftMXQ1yKXlrsJJGey8mFmuJgtd1fg0OHYZ6UwZIhttBkO6uGecpjfx6aWn3vttvOVg2F8Z6gGG3yiIWP4m56StSol8Q2dm6Bi1kCujEeOWJCfvbac0eYedFcYVv0OFobb3XMUd/V07b5RVGNDYSkmwzX2uG2sEIuQy5cGEiaq5uU/Qj+ATqasycbdgzM873waE+pWtPtvTIWcA4j9NBrdWKUZHK/nDz52gFYc1pFICQc30g6dKk2HEcp4mW/3Kr/y6pGjAN1OrOPPQsQUE7k51DKdAH7r66TpseYJQD8trsSNl0hHGoFcfeSyCmMK/ef+jbseqD9sMAropjcW3kOeiAKWy1c063fi3jjvRYX9AoSDg1GVu0Rns1tV8ro42gLxJC7LEc/K8w6BokfqI2rDj3dEuIApFWF7gNbtnIWqPnHr2kvsRlpedRejXiB3mI13SU2Q0nDj+2VDvl4zzjvVVlrWXaBmFx3T9/EtVG3pkrAy+13Fwy8843sEQ973pqzvgwNo7HSxVNCI5VjVSPq9HoAoyvkfyBkR+mntdzQc1mqKI4MZqJcUCI228Q7GMxEP65bRGG0DDzuXYvf835DCRIAsI9Px0J/4kI8gUXYxVhgokljx48ptSbkz9xBySymq9X+AJADWLcDjkEyRaqI422jS6svkpLkopKwD7W+qxc6UbvTkfBow0PicW1X34GlFJ1RQxp0c/iIS+MSoKmKF9l5Z2tjBYz4HsgFv/t34kmdWEY2sY6JMNfttMzRsJ0c+bFKejR6eS03WwhWsgwtKjCIljNdQbntN7dZb0zeE+KoRCqMHd7rkMqRwezm6BdR/k93HckW9+FmQHjHM31heghH+MKjiO6FYZgP9Ei1fuCxm pRKGw7Qk obnqVxQ9ZCjUm/eGls1F8OwbMkzbYEVfWIp8sMLPL81Ooz1yO4mspY16eiGi4LPrAfJlQta1t0tGR4v+5ImC/NGp2YesQ+NAzH6oAgJggWhaofqQcGAHrTaSLuqXKJmbaUt9yTtju3Yvw3WyXNj4vwHIXx9gZ60D5pfJHBBoeE+TKQD6y8iYTE85A47ibl9zgXDxkNsyHR/2G0V4yHcQp1wRluCvYzNfwOsiTW7l3jhmy5/keSiR1GfUXDMRjOu5+BmqNfbacVOGLQamqi3IgpxQqWsF2izLarN1sMiuyCXmmXauRM10W8tkIH+BnRe7FDmtWiHU+tXFoU7yh94o4Yv6DSz6dS9i38SWDQpoOJp1CIZEoIGMD47BqruPbx+4eM6SfjwTAnpcN8bjMxKXDSflFpNgj/Xem9lx8cmA2jmf7L88= 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: List-Subscribe: List-Unsubscribe: On Thu, Jun 13, 2024 at 6:47=E2=80=AFAM Andrew Morton wrote: > > On Wed, 12 Jun 2024 16:12:16 +0800 "zhai.he" wrote: > > > From: He Zhai > > (cc Barry & Christoph) > > What was your reason for adding cc:stable to the email headers? Does > this address some serious problem? If so, please fully describe that > problem. > > > In the current code logic, if the device-specified CMA memory > > allocation fails, memory will not be allocated from the default CMA are= a. > > This patch will use the default cma region when the device's > > specified CMA is not enough. > > > > In addition, the log level of allocation failure is changed to debug. > > Because these logs will be printed when memory allocation from the > > device specified CMA fails, but if the allocation fails, it will be > > allocated from the default cma area. It can easily mislead developers' > > judgment. I am not convinced that this patch is correct. If device-specific CMA is too small, why not increase it in the device tree? Conversely, if the default CMA size is too large, why not reduce it via the cmdline? CMA offers all kinds of flexible configuration options based on users=E2=80=99 needs. One significant benefit of device-specific CMA is that it helps decrease fragmentation in the common CMA pool. While many devices allocate memory from the same po= ol, they have different memory requirements in terms of sizes and alignments. Occasions of memory allocation and release can lead to situations where the CMA pool has enough free space, yet someone fails to obtain contiguous memory from it. This patch entirely negates the advantage we gain from device-specific CMA. My point is that instead of modifying the core code, please consider correc= ting your device tree or cmdline configurations. > > > > ... > > > > --- a/kernel/dma/contiguous.c > > +++ b/kernel/dma/contiguous.c > > @@ -357,8 +357,13 @@ struct page *dma_alloc_contiguous(struct device *d= ev, size_t size, gfp_t gfp) > > /* CMA can be used only in the context which permits sleeping */ > > if (!gfpflags_allow_blocking(gfp)) > > return NULL; > > - if (dev->cma_area) > > - return cma_alloc_aligned(dev->cma_area, size, gfp); > > + if (dev->cma_area) { > > + struct page *page =3D NULL; > > + > > + page =3D cma_alloc_aligned(dev->cma_area, size, gfp); > > + if (page) > > + return page; > > + } > > if (size <=3D PAGE_SIZE) > > return NULL; > > The dma_alloc_contiguous() kerneldoc should be updated for this. > > The patch prompts the question "why does the device-specified CMA area > exist?". Why not always allocate from the global pool? If the > device-specified area exists to prevent one device from going crazy and > consuming too much contiguous memory, this patch violates that intent? > > > @@ -406,6 +411,8 @@ void dma_free_contiguous(struct device *dev, struct= page *page, size_t size) > > if (dev->cma_area) { > > if (cma_release(dev->cma_area, page, count)) > > return; > > + if (cma_release(dma_contiguous_default_area, page, count)= ) > > + return; > > } else { > > /* > > * otherwise, page is from either per-numa cma or default= cma > > diff --git a/mm/cma.c b/mm/cma.c > > index 3e9724716bad..6e12faf1bea7 100644 > > --- a/mm/cma.c > > +++ b/mm/cma.c > > @@ -495,8 +495,8 @@ struct page *cma_alloc(struct cma *cma, unsigned lo= ng count, > > } > > > > if (ret && !no_warn) { > > - pr_err_ratelimited("%s: %s: alloc failed, req-size: %lu p= ages, ret: %d\n", > > - __func__, cma->name, count, ret); > > + pr_debug("%s: alloc failed, req-size: %lu pages, ret: %d,= try to use default cma\n", > > + cma->name, count, ret); > > cma_debug_show_areas(cma); > > } > Thanks Barry