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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 5E22AC3064D for ; Wed, 26 Jun 2024 07:21:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:Content-Transfer-Encoding: MIME-Version:References:In-Reply-To:Message-Id:Date:Subject:Cc:To:From: Reply-To:Content-Type:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=moCiPaIn6NwSfydLRZyrKy3vd1OTZl2jw6RofluiaGs=; b=PikRJBKwV1NXbKye+/xWDSOh4R 6/XGdgohNZIZXJXsk5oSfv0BkW54z0W5/20BlTQRQd/BGcNAixgMHMNSwplyZdTcsk35OdNpDY5Rh CaYe+er+3FEVJ7CHLnnvzeOQYGrSrvS1NmjcnAZCpdil4Rlqu2vEQogdIc4HTUXt2K3uYVBKYhScS kJMAEKlAbfbM2tNEpghICEJpjfpI+2/pZYImg1TwCXvBFJ6r58Uk6P4BGdtlsrSy4uOT9/rk4Theb Ax2z/vV/IAJUXPrfzM7jlLsJPChkUM3mOHnKHY/JABC+YfqY+Cskx7N6Gt/EcIhpYCpbhNQnOiU4r wNo6UDsw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sMMxu-00000005i5g-0964; Wed, 26 Jun 2024 07:21:14 +0000 Received: from linux.microsoft.com ([13.77.154.182]) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sMMxl-00000005i4X-2BG2 for linux-arm-kernel@lists.infradead.org; Wed, 26 Jun 2024 07:21:08 +0000 Received: from thinkpad-p16sg1.. (S010600cb7a0d6c8b.vs.shawcable.net [96.55.224.203]) by linux.microsoft.com (Postfix) with ESMTPSA id 3DE0D20B7009; Wed, 26 Jun 2024 00:21:02 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 linux.microsoft.com 3DE0D20B7009 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.microsoft.com; s=default; t=1719386462; bh=moCiPaIn6NwSfydLRZyrKy3vd1OTZl2jw6RofluiaGs=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=G9EeXrw+/0mJx1pij6BPmT+TnZdwksClZtLPrzVUXgEKvyh9KLmAN+bY+kJ5kgNom MFyu/2j/wa+nzn9EqTks0cn7GZH27tnPkawPFxkWRlLsV9rPpRfOLVMYG4x0WX87hS dE97G7JmI5FAdMeJR770S7ATzYaaz4MdKCiwCrW8= From: Shyam Saini To: dan.j.williams@intel.com Cc: akpm@linux-foundation.org, david@redhat.com, iamjoonsoo.kim@lge.com, james.morse@arm.com, jgg@ziepe.ca, jmorris@namei.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, maz@kernel.org, mhocko@suse.com, osalvador@suse.de, pasha.tatashin@soleen.com, sashal@kernel.org, tyhicks@linux.microsoft.com, vbabka@suse.cz, will.deacon@arm.com, code@tyhicks.com, srivatsa@csail.mit.edu, apais@linux.microsoft.com, vijayb@linux.microsoft.com, tballasi@linux.microsoft.com, bboscaccy@linux.microsoft.com Subject: dax alignment problem on arm64 (and other achitectures) Date: Wed, 26 Jun 2024 00:20:38 -0700 Message-Id: <20240626072038.1419889-1-shyamsaini@linux.microsoft.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240626_002105_668271_B0209050 X-CRM114-Status: GOOD ( 22.16 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi Dan, Restarting this thread to get more insights about dax alignment problem. So having a devdax pmem of size 128M is [1] not usable and entire memory is wasted? For 256M size devdax pmem, again 126M seems to be wasted and only 128M can be hot added/removed. This was observed on ARM64 platform. do we have any potential or existing solution for this problem ? > > > > > Since we last talked about this the enabling for EFI "Special Purpose" > > > / Soft Reserved Memory has gone upstream and instantiates device-dax > > > instances for address ranges marked with EFI_MEMORY_SP attribute. > > > Critically this way of declaring device-dax removes the consideration > > > of it as persistent memory and as such no metadata reservation. So, if > > > you are willing to maintain the metadata external to the device (which > > > seems reasonable for your environment) and have your platform firmware > > > / kernel command line mark it as EFI_CONVENTIONAL_MEMORY + > > > EFI_MEMORY_SP, then these reserve-free dax-devices will surface. > > > > Hi Dan, > > > > This is cool. Does it allow conversion between devdax and fsdax so DAX > > aware filesystem can be installed and data can be put there to be > > preserved across the reboot? > > > > It does not because it's not "pmem" by this designation. > > Instead if you want fsdax, zero metadata on the device, and the > ability to switch from fsdax to devdax I think that could be achieved > with a new sysfs attribute at the region-device level. Currently the > mode of a namespace with no metadata on it defaults to "raw" mode > where "raw" treats the pmem as a persistent memory block device with > no DAX capability. There's no reason the default could instead be > devdax with pages mapped. > > Something like: > ndctl disable-region region0 > echo 1 > /sys/bus/nd/devices/region0/pagemap > echo devdax > /sys/bus/nd/devices/region0/raw_default this interface file seems to be not available can we use sub-section hotplug feature here, there aren't much details available about using that, is it via sysfs ? I appreciate your help and guidance on this. Thanks, Shyam [1] https://elixir.bootlin.com/linux/v6.10-rc5/source/drivers/dax/kmem.c#L102