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 451B2C27C53 for ; Wed, 12 Jun 2024 18:47:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id CE9AE6B009E; Wed, 12 Jun 2024 14:47:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C997D6B00A0; Wed, 12 Jun 2024 14:47:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B60FB6B00A4; Wed, 12 Jun 2024 14:47:55 -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 98C356B009E for ; Wed, 12 Jun 2024 14:47:55 -0400 (EDT) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 330104032D for ; Wed, 12 Jun 2024 18:47:55 +0000 (UTC) X-FDA: 82223120910.26.7D9E64D Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf05.hostedemail.com (Postfix) with ESMTP id 8FCBC10000B for ; Wed, 12 Jun 2024 18:47:52 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=Sm1lqskG; dmarc=none; spf=pass (imf05.hostedemail.com: domain of akpm@linux-foundation.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1718218073; 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:dkim-signature; bh=2vLx8l/3Bbfbnv9jtOZcdiwXnPjhOPqR32th3903ZDk=; b=jMvlLjIGvmwZuHgfxe34PlqZc2E4vmPbN9YgNZ7eDojKUJcnDpF6jFiA5r8CG3dltelQcW f0bhO9NgSUoeEVLAYTNlyjJpgakp8UbxWIzo1ZZf+FSRBd+Lql1RaEeJV23frENyU5maaT rkH6pmWPclAHcNW4Led5h/kra8eigd0= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=Sm1lqskG; dmarc=none; spf=pass (imf05.hostedemail.com: domain of akpm@linux-foundation.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1718218073; a=rsa-sha256; cv=none; b=M/k8l9EJL9pomBTLwFYUmW+aCNrQMzjmkiOusleHiIG/oggmobi7E8gRR30vfIsniGGiFh w/OuNDVwF8rTKcFA9XpY5dKhSpwyMOHnDQ/mlO4uUI0saeBqZqpVOSGZ4M9FxrtXWohu1I tIBLHn4wlh+qPV8xIUg8za62TXQVVns= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id CB8FFCE0B1B; Wed, 12 Jun 2024 18:47:49 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B53EDC116B1; Wed, 12 Jun 2024 18:47:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1718218069; bh=WAdPbpV16su/L/nLL1I9OCKFq9jqJsizJUL/5Q609jU=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Sm1lqskGRET2keI9nUnBWAo9NHejyLojU8nIbdRINQDTbTFnHquXRBI3amEYYfRqf MHr0NVCg3m01gJr8LppX/w5oXog83ISpT/eeV4yrRIZimnxBuRdW1qLNYfTy7IEt4I JHmCDvtnsf7cXRN+5v4SiohSXp6hI5njlG4cKRtI= Date: Wed, 12 Jun 2024 11:47:48 -0700 From: Andrew Morton To: "zhai.he" Cc: 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, Barry Song , Christoph Hellwig Subject: Re: [PATCH v2] Supports to use the default CMA when the device-specified CMA memory is not enough. Message-Id: <20240612114748.bf5983b50634f23d674bc749@linux-foundation.org> In-Reply-To: <20240612081216.1319089-1-zhai.he@nxp.com> References: <20240612081216.1319089-1-zhai.he@nxp.com> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 8FCBC10000B X-Rspamd-Server: rspam10 X-Rspam-User: X-Stat-Signature: 3ndrfgzdfhtzcf7uzmp59a6gjmgpfupm X-HE-Tag: 1718218072-191908 X-HE-Meta: U2FsdGVkX1/H3lBwI2539wX+nkS93t9C5fRd7ocsEHFIK0WLfIeMXIHeW3izYmAlNWmTeLMpvJTm/nz5fv+x5W8w9DRQDx/RhGSyrBZDcdfBciLfqXKK5oH0z6FJrubKQTlhgyGbzIvpjqEA1H8+8sXkd6WXEVfISsi1XgKupoMASDHsZeGtwZkteYBwz9tfChS4zFG3LIruGT5BoQyPXT2ZLCVwOgn9Xn83HKbhFiobpgCLHH+78aCnVQcVI+Tevu83H9MziLd1ox1cD8BPnrR4MU7kye02pbhf4hj+9Za0ciKR9prxwdycyeIT2PZUmIhh7XpywsqB0IHjs45XYg/htn4tvMiGp3rAvk9JXf2U4yZV7r22Ix47Bp3j/FFY8561WSLCXQsZOHBtCAiFjs31RQ4o4iI8Nj7Sb/tCIL0nLQPzCL/imo7PvG5gjzaC3k+e5sXFnc8ZYM+Z5dfWCKJMFjZe4JqPsf6G4hX4mgXNYwhA8FEL7eywWyUF2Cuevr5xnmP6bzwTLZ9CSAXFiebBUCyPqoDwN9Ootz7Z0xOOdO4G4K7YeM5EB6DIKpqB3KFtleUQRoE8j1LtuH15nFcmJOxmRbJBXk/xJCLEZ7/H/5bAdqO1vTvr3uZ400xhcqQHUynsLoQtChoCAx/+YbFj8O7jlCk3V+UqL/RxZD+/WUkQ/+/wGynsXpqQlNrYojtwo7eb2ZBLXwkh1x9T48EEy4WdNDxW0NH0mxbHgnW5RE2kujOSSUEljVzGnchEC3NSAH9NlBZg3dUb01XyL4xL29M0iCuPhNK/ksAb7ghoZ9gzZNOv0UDwH0HVz93e20W5EPgnlg8Td+0coLz2gGFqDyi4ZN1K/msxCqAwN0dYNf1dPYTR43YMo16fXzu1BHJ4Zeeuk23wqoGyaGRwIOb0vJ0lzl/Pd4JQvaeBEouDrgWBdGFjX3aiDm4SpttSfjHWqX1iDllX8ObZng3 JWbOcR2D 72ySAJjR/tmcmjsqVN7HRubjHwnJaWuvjx+//6ccqL2p99UcIxiGEyaZXyZoSBXRt4zr/5ux0xb2l6UeSjHQAnQ+p5uPoJaPtE9VP2J/BqN0ljvTtoOGODERyIe5ITZqm7Zp5iiTJFsB/5IXSd2Xiqm1xqsOe4X8nVsI5r4SrtfKAoIlWbQDVMc24b5UrbM5LNImqAIs/2VGzg7bXR1UiSwmXlPIo58sqDnOg83gYS4v8I+sZZ23mSBI8XIPwzBHiUL3zUGah+2JOpX/5yHt7l2gRg6JfIFTmE4l30IV1XyZWB2GyYEXeeQ9Kaw== 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 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 area. > 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. > > ... > > --- a/kernel/dma/contiguous.c > +++ b/kernel/dma/contiguous.c > @@ -357,8 +357,13 @@ struct page *dma_alloc_contiguous(struct device *dev, 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 = NULL; > + > + page = cma_alloc_aligned(dev->cma_area, size, gfp); > + if (page) > + return page; > + } > if (size <= 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 long count, > } > > if (ret && !no_warn) { > - pr_err_ratelimited("%s: %s: alloc failed, req-size: %lu pages, 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); > }