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 7D8C2C4345F for ; Tue, 16 Apr 2024 12:06:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E89D96B008A; Tue, 16 Apr 2024 08:06:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E39F76B008C; Tue, 16 Apr 2024 08:06:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CDB876B0092; Tue, 16 Apr 2024 08:06:55 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id AE4916B008A for ; Tue, 16 Apr 2024 08:06:55 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 7D06C1C0F93 for ; Tue, 16 Apr 2024 12:06:55 +0000 (UTC) X-FDA: 82015268790.27.2BD6C65 Received: from mail-pl1-f169.google.com (mail-pl1-f169.google.com [209.85.214.169]) by imf17.hostedemail.com (Postfix) with ESMTP id CCDB14000E for ; Tue, 16 Apr 2024 12:06:53 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=P5itgFUT; spf=pass (imf17.hostedemail.com: domain of skseofh@gmail.com designates 209.85.214.169 as permitted sender) smtp.mailfrom=skseofh@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1713269213; 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-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=5bxCFPrPN7YYp9G6q6vxreo9zNUW585IcR1CQUImrPQ=; b=WxFcHNxm8oK6yTWPPhELtgi9gQHsUpKzCf1wNJ5DVQtMH9myyYKRFZnWYRfHuA4vBOSJ6O obEqI4um1SQdAca3RbBkiQDVgiaNNwybPRAWWUi0nnMjJiaSGLetwNrWWEosw6OH0cxI8V wQV/golXTEM5l8gfyXBGwiJeaxFd6Uw= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1713269213; a=rsa-sha256; cv=none; b=H5Ey+mr2z+Pl7TEu/9+JaV12FcBMh0zwvgTbAdBs0o8k+OsSZBBW5ChKFD7rPgPEvNTliw U6EHAS6cIsfrhsDDiy9HhlwPfitypIHruMN4uiTUcB6G3CvBsIL7CYo5bDAZd5FNM6XDVU H6DLYgLlvKhqaSVMEIDwy/swzX553yw= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=P5itgFUT; spf=pass (imf17.hostedemail.com: domain of skseofh@gmail.com designates 209.85.214.169 as permitted sender) smtp.mailfrom=skseofh@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-pl1-f169.google.com with SMTP id d9443c01a7336-1e50a04c317so22046845ad.1 for ; Tue, 16 Apr 2024 05:06:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1713269213; x=1713874013; darn=kvack.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=5bxCFPrPN7YYp9G6q6vxreo9zNUW585IcR1CQUImrPQ=; b=P5itgFUT6YoEs18p2b867d3EGM16pKwdZS0FAUpNTfNcOpJ+danI4Z3k5gCsTIJ/Kg vmrHG5aErLvxA5HjzRopgN9kiPRB+Im2Pp9jYTW3GAkrgFSYeFFOJr7rSVQpgTIn4xvo y+zZaAKhTEP/2us+1OuwaoY2VJPplcZRrIQcFdqqH7zBzWp1pNDG4iac3NVI4nEGx665 pz1KJI8mpINCrvU82wUB6EDIRtwQwxsTzYMmnBUSVf8UkK64jEBUmLpLFDb7Vse26zNE mxuePZ2lJtKSvHORjbH0XjYonCwzTVYc1UE/TueZwdiO/U1u81Ss81vkVBkreBVzBC85 kJMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713269213; x=1713874013; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=5bxCFPrPN7YYp9G6q6vxreo9zNUW585IcR1CQUImrPQ=; b=Kxi4niVSNg5Z53rhtPKxYI3pnwnlh+wHxDjR8ioEgRb2DSdEOZ9z6UU6gBbktRyvoq fLXNnRzG11vK1E8US/2l2TAG7kGboA94qqcHCUGjkgRddMaSfS5GaWJYn7Fx6T3LeEkV icu+pUpFKYis/rMxebCwY81crFISHhvc1DFnd0l032tE5XCaz1hZZ6xWJnWbqabT9Y3l 5cn60jAdtz6HHOa8jAZibr+8snLMjkHVgioNOZH7r7EqI99LCOizyXJF+k0LxRjy/HwZ tN9qbvhPiqJYGc3ecGQtZAq9Mol+2jGCNIAfwd7woaI7Ptrg306S7NTDe6SjnUXxjRwu Tb/g== X-Forwarded-Encrypted: i=1; AJvYcCWGnb1f2/nBoJsKV3ZGrAD9WK9SCUhlkUMwnPNmvxIWPGgD/UuXnn7ATxoHyXPupOcCxiatIDvODw7dtzdsB/iPrMg= X-Gm-Message-State: AOJu0Yy0VegO94OboW0ptalSkb1n6caYLZE3m5LnlLwpF/tOD/N3mRaG wSUrqsdOdhRA+4N6IsrVVgZ6HJpKE6FvcVr59fbHO+fYEOh+EWun X-Google-Smtp-Source: AGHT+IHJUj+W9eJafOlJEfgDLN0EndGh1v6rprUj/GjSniPiLyQ1kYUQIqtp8KYoLEs3BGKJk++KYg== X-Received: by 2002:a17:902:e9d4:b0:1e4:1bff:1f6f with SMTP id 20-20020a170902e9d400b001e41bff1f6fmr9339067plk.50.1713269212500; Tue, 16 Apr 2024 05:06:52 -0700 (PDT) Received: from localhost.localdomain ([49.142.40.215]) by smtp.gmail.com with ESMTPSA id b11-20020a170902650b00b001e509d4d6ddsm9813684plk.1.2024.04.16.05.06.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 16 Apr 2024 05:06:52 -0700 (PDT) From: skseofh@gmail.com To: robh@kernel.org, saravanak@google.com, rppt@kernel.org, akpm@linux-foundation.org Cc: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: [PATCH v2] memblock: add no-map alloc functions Date: Tue, 16 Apr 2024 21:06:34 +0900 Message-Id: <20240416120635.361838-1-skseofh@gmail.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: CCDB14000E X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: wsejmww5prthea1oncwc4nhs89ykufa1 X-HE-Tag: 1713269213-196372 X-HE-Meta: U2FsdGVkX18IXAAehKkK24kSyMJ1rWAe5V1HOJtfJp1MjnRFPRvqUZ8xL45YpXkrsKC/JtfeyA2xv6cdpVh64RKmGx0d7H+HnpuF/onz7n6yKs3azvQt60SA+DKOITZPTTWYrY6xPwm4wjltJcPzg1RYAax0jMKbibaV/xYHZ6sGtD1LQdCGJxKU+Tmdj0DoDecXLxu7r+2/pryz8K/4sw2u/44uK8rtGFpqsVTrFR5Vs+lXiLHaH8Tn7cmRHQ1awMlJEJwoRqD1NX0EFOXqkaGVSIqqhoOKaYRvG1QWgToO4Xt/uxoAkeG44CAxT4vQ4t3LL8rcQ77azO2QuItoY1dxB6H+3baKuZ7xWLxu5usJdl/Sns3FB2MzmKaebQ5Q5OVNV8RUMSKGoswd7yUo/WD4cYMBN9q9gIay+0haHyFEFmIVgLSvcIG8ShB/GK+myVsUOx14FWqr4mITYZw2azK4n4t3IvcYPf8H+97sZLrUaQP+2338OnBTatobDmsSZszaRQMNtN7R5W2U3T6C8s+Q2wVpvvLM/e+lNX+a4XGnDVlgaRApJ1LRDCNfBvY36K7LtOI25iZQit+cqmehAGVg+DBOIbtA34LGAH/L2cOpvnJcoyb0Rc6KS80AMvaJhYPa0XAFttfcGfO8Wf4QQbsF9xQB/UB0XnqCC8tjcZtas71ezgjJUY65+jWp/yBO37t7aAPy8IeC0N+3MkUvX4n3xGGnjdDUSPrc1QKimH3MQj4d52sBsIVOZ3jA9ZbbDmHUwUTP+z1A0tNtDCfEU5EJY8kpxEnW7W7hc2acZIVERwhTJ5oJgqhEDiKrKyZ8fLc6vIhgXAdZ5Ibk+yK8IWLBy8IM/1VSToxw2w7zBue4HYRCTVk4ZrrlQr49txyk1y1jpNc6H97tPtbOknXWz/JaFmiDmQhBsJjV3xi8mbh4K4orOJFhmavVvN5Uq7SGiTmyWLGtVb3Zw4xxnxq IZaJdNy4 c+MGmw0SL88oS8Ohud5dB/O9Ke+sAEl3d/AhyoYO+JMKycta0eVvrlLpTQQDQomXClf2Y0IsdIBlrbfizP6R4/ErbIEkT9Ms9tMQNJqDpAsZzBzU= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000083, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: > > From: Daero Lee > > > > Like reserved-memory with the no-map property, there are memory regions > > need to be allocated in memblock.memory marked with the > > MEMBLOCK_NOMAP flag, but sholud not be allocated in memblock.reserved. > > Can you please explain your use case? > Why do you need this functionality? Thank you for your comments. I added a example to the commit message. > > So, functions were added that find the required memory area in > > memblock.memory, but do not allocate it to memblock.reserved. > > > > The early_init_dt_alloc_reserved_memory_arch function was modified > > using the no-map alloc function. > > > > Signed-off-by: Daero Lee > > --- > > drivers/of/of_reserved_mem.c | 9 +++-- > > mm/memblock.c | 78 ++++++++++++++++++++++++++++++++++++ > > 2 files changed, 84 insertions(+), 3 deletions(-) > > > > diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c > > index 8236ecae2953..504f2f60689c 100644 > > --- a/drivers/of/of_reserved_mem.c > > +++ b/drivers/of/of_reserved_mem.c > > @@ -40,15 +40,18 @@ static int __init early_init_dt_alloc_reserved_memory_arch(phys_addr_t size, > > > > end = !end ? MEMBLOCK_ALLOC_ANYWHERE : end; > > align = !align ? SMP_CACHE_BYTES : align; > > - base = memblock_phys_alloc_range(size, align, start, end); > > + if (nomap) { > > + base = memblock_phys_alloc_range_nomap(size, align, start, end); > > + } else { > > + base = memblock_phys_alloc_range(size, align, start, end); > > + } > > + > > This changes behaviour of internal function, what effect will it have on > the users? I added explanation about this to the commit message, too. Thank you.