Received: by 2002:a6b:fb09:0:0:0:0:0 with SMTP id h9csp3933997iog; Tue, 28 Jun 2022 05:56:21 -0700 (PDT) X-Google-Smtp-Source: AGRyM1s37hvUu7lSkJoMuwSmAjC1WgruJEVYVFlI+eaiJh3Mb/4pNzS7aKAtuhrUnIz2noEXx05K X-Received: by 2002:a63:2a4f:0:b0:40d:997:557f with SMTP id q76-20020a632a4f000000b0040d0997557fmr17401237pgq.42.1656420981694; Tue, 28 Jun 2022 05:56:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1656420981; cv=none; d=google.com; s=arc-20160816; b=eRjUWAO+Bimtn8fZIKnj6rotvn9MMpJU8suFSgMIL3Y1lLOcE7/lOSeUBRvma4DsAh 00Gm5Ltqvtd6+rIQDT2sYE44URQ31aBNpyqTs1dilL0qD5KkKEbXWlKZx66El+BQZYe9 wEeVotHLf0XhoEZgOUptAAz7pLr+U6x19nlnXEm4zeTYZJR+gbulsd7J8C0PEUr0Z3Z3 +u1ZWtMKkDyuBa2YDFG20SN4xoEsc1TpMgrHCjjfSaEls7IUfscIOtw2cWRBliLrIUqQ x3ao2We6XVXaXXEOMfnJbciv123aj82zw4NU8SejBDC+cPVlevkxwTSLo1C4L1VvK8JJ POfg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=ew4GY/jK0/nNgtH7SJeMlPioCDoaamIUs3ZnK2M3w5E=; b=OGx4fd0uiUUuVu6jAoeQ3FtJMWS46B4RUrpIA0A/XRryaYj1f4tqrK1rDbf3AxUCWd lDtp52YBcuyGs+PwS2Ky4hb+z7BXGltPSI/ozg0F7DybGclUHXX0CThZ3GxSTH8S9MQv NNTIqxMf56iIz3CfPbHgXjebVozjIwz41zGTroih0/jDATMzDdhaCSVzNyWV/lXoc/HI g8IkW1u4FjRW6Cj5+qHgMfXuv/RYkCIgXCMoGFdIIVSXhe8xmVwJSPTWV0yT+Labh4Qz JSKE9hC0JvbQmqZz12bPG+nuLXJVVw+SCU2c3uYif49q+SXt9RPidaOvy+xIa81SaDO/ itgg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@bytedance-com.20210112.gappssmtp.com header.s=20210112 header.b=7+OrJqXH; 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=fail (p=NONE sp=NONE dis=NONE) header.from=bytedance.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id g3-20020a636b03000000b0040e3162f1f5si7253840pgc.118.2022.06.28.05.56.08; Tue, 28 Jun 2022 05:56:21 -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=@bytedance-com.20210112.gappssmtp.com header.s=20210112 header.b=7+OrJqXH; 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=fail (p=NONE sp=NONE dis=NONE) header.from=bytedance.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1345834AbiF1MbI (ORCPT + 99 others); Tue, 28 Jun 2022 08:31:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59618 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345827AbiF1MbG (ORCPT ); Tue, 28 Jun 2022 08:31:06 -0400 Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 46EBB2ED54 for ; Tue, 28 Jun 2022 05:31:05 -0700 (PDT) Received: by mail-pj1-x102d.google.com with SMTP id a11-20020a17090acb8b00b001eca0041455so12015213pju.1 for ; Tue, 28 Jun 2022 05:31:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance-com.20210112.gappssmtp.com; s=20210112; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=ew4GY/jK0/nNgtH7SJeMlPioCDoaamIUs3ZnK2M3w5E=; b=7+OrJqXHyc9fE+RnOg3u2ePtSunThr293XZZGGJAov+euIE8grcxieCkv+pgLujeGY BsPTKiPOfs7RacJUPeY7vcXMi2fIMRc0eNE8XmvjiuFqVTfaQsClkGhMMDF+RWOu7wmP x1EJ8u3Cq4zhOPWaD/2J1HFAoFqxEnWr2TrSJADR/1iAll7iQ6OkMLVrlhbTfb2Io1V2 Y0nj0VWWf29/wtyN/b1zPf4Al5+i6ZDDnzxTJMSQDy+TSUxP4iq290Ytilz5DI5ulTYJ AlcqhaqCimP3IiKa6ep18/y9elgCWHlxQs6mtJGuKdVx8q6TXnXBLsXlY837ApDYswvO Js2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=ew4GY/jK0/nNgtH7SJeMlPioCDoaamIUs3ZnK2M3w5E=; b=zrPAadcF3QbLMk4WNNRBLg67Dh/W4Wi+9vYkHrEfcDePOEwd7b0saHhn5FvkXQI9+h B0E1Cm9yl7TwkWwq9pUHfP4tsDNGJ86dF+G1vkH0kWo9HbiNUJ1yd+4IOzgsTOegIsyK MhIzS51kxjFJ3L4VziXNJwEMqItwHK2u95EmaFe6GCLTUz6k/KzEAh9iH+c1PtLgadYX +bX9JfoMgUqMYeLTUsd14UwVS0c3PPnKm28YIyjg9hHzREqLKS6hnjNBGxJidFLFrtqD eDlwN1vhn7e6hsfefGiKijKAKKFjFCRZiUgn7GRB2hIlTJsm1L9wk3DhfSxU583OybLM A5GA== X-Gm-Message-State: AJIora9tEISjEhlI30A7gR0Q2x/2RZZkQCYgReoewDz77V5bTfKeELFg Pxzbzmxa2DOdNYcaccQ2DrAZzw== X-Received: by 2002:a17:902:7282:b0:16b:7a53:3b41 with SMTP id d2-20020a170902728200b0016b7a533b41mr4699654pll.1.1656419464798; Tue, 28 Jun 2022 05:31:04 -0700 (PDT) Received: from MacBook-Pro.local.net ([139.177.225.225]) by smtp.gmail.com with ESMTPSA id p26-20020a056a0026da00b005251e2b53acsm9275986pfw.116.2022.06.28.05.30.59 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Jun 2022 05:31:03 -0700 (PDT) From: lizhe.67@bytedance.com To: dave.hansen@intel.com Cc: bp@alien8.de, dave.hansen@linux.intel.com, hpa@zytor.com, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, lizefan.x@bytedance.com, lizhe.67@bytedance.com, mingo@redhat.com, tglx@linutronix.de, x86@kernel.org Subject: Re: [RFC] memmap: introduce cmdline parameter "memmap=nn[KMG]$" without start addr Date: Tue, 28 Jun 2022 20:30:51 +0800 Message-Id: <20220628123051.14414-1-lizhe.67@bytedance.com> X-Mailer: git-send-email 2.32.0 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE 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 On Thu, 23 Jun 2022 07:06:36, dave.hansen@intel.com wrote: >> In our scenario, we need reserve or alloc large continous memory like >> 256M in machine which have different memory specification at just >> boot phase for a user land process. > >Just marking the memory reserved doesn't do any good by itself. There >must be some *other* kernel code to find this reserved area and make it >available to userspace. > Sorry for not describing clearly. We wanted to use /dev/mem as our interface to access the memory from userspace. So we don't add other kernel code. >It seems kinda silly to add this to the kernel without also adding the >other half of the solution. Plus, we don't really even know what this >is for. Are there other, better solutions? I certainly can't offer any >because this changelog did not provide a full picture of the problem >this solves. Again, sorry for not describing clearly. Here is our scenario. We need to reserve large continous memory at least 256M in 512G's machine, and need reserve more memory in larger machine. A userspace program will use it through /dev/mem to store some data. Besides, a hardware will need the data stored by the userspace program to do it's job. Why we need continous physical memory is that our hardware can only access memory without mmu. So allocing an area of large continous memory for userspace is the best way for us. Considering that we have several type of machine with different memory specification, so we want an easy way to reserve memory with only one size parameter. I find a better way to realize the requirement. I will send a v2 patch soon.