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 A1A89C433F5 for ; Wed, 6 Apr 2022 01:23:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DE9506B0072; Tue, 5 Apr 2022 21:23:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D970E6B0073; Tue, 5 Apr 2022 21:23:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C10B66B0074; Tue, 5 Apr 2022 21:23:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0002.hostedemail.com [216.40.44.2]) by kanga.kvack.org (Postfix) with ESMTP id AB01C6B0072 for ; Tue, 5 Apr 2022 21:23:11 -0400 (EDT) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 60A32AB9AD for ; Wed, 6 Apr 2022 01:23:01 +0000 (UTC) X-FDA: 79324705362.28.07736D2 Received: from mail-pl1-f175.google.com (mail-pl1-f175.google.com [209.85.214.175]) by imf19.hostedemail.com (Postfix) with ESMTP id 973E11A0007 for ; Wed, 6 Apr 2022 01:23:00 +0000 (UTC) Received: by mail-pl1-f175.google.com with SMTP id y6so663067plg.2 for ; Tue, 05 Apr 2022 18:23:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GpAHmbeaClOABfDOq4xnFecCsaGHIekoRhkFacwUlXs=; b=DTGX679OZ1qKODLoERzJPs9u5x0CQ7BYYUpa2ouElTHNgAKbPpKoCPRTExB81qQ2US 94dbMKZq/YmOeyWFp2JbpnvKA0jH4iSww8lz1A4p4C92e1wGL/hPVnaXi1g1ADkUAp6P RNhUno+35Z8wecDtsPPgH+m4yLNmQXPQLqx3+K7wiP9W7njPgLJqsTd3C7bY0GOn3iL4 DU1KcaQsM6ar/F3C6nMFoc7ou3I3CvJEUZey03r8p0CmPUzHrg/bmaACtqdejQJ4iant V/TCZoYpa1rMEzqemePJkaBICzpAtqcCLdOPBkkwkXyPjciIJJUh7pdnmRJymCr3P0SZ hABQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=GpAHmbeaClOABfDOq4xnFecCsaGHIekoRhkFacwUlXs=; b=xBkf1Ffw8QugKDjoGQQgyv8k4EkPCBsabG/NIEZrZLg+4AcKwOId2YvMofWmW4ZWe0 ku7eTX/kyhYuiqHoB8xbHKb7VGOnD+z2KGgNAPt0EoLuoCgnlt3IoS3Je7O1uhLr0QAz W5SuS96DW4c2/q/SGCZ6xeBkVM6JiDbgz6FyQcPaVyTepJOPyTv3+xV7iUioxc5Jl65c vGWAtEL47TDwkrUpunhkO8wUkbDFG5uwE4agexHUmjIrPldW1gzBXWduZqvVWV0gmFFx i7HrzYZTSoo/oRYOoW9cDcuuQsCiYPVzdIC7TbNuecsFTJKVFhP0ti+KsR7lgPkojv3Y aOew== X-Gm-Message-State: AOAM532freKF5zLwzgk9ME4oP8mjgBTRTzUTOuTXCzAO4IebmImLNNWx D0kis6Jg+w/Lw2joat8mMgOvfUGLsAQXo3dENHhSuQ== X-Google-Smtp-Source: ABdhPJy2l3ev5j2Q7pkZUUiX17H1f2uX0JiaFPO6bc09C7QOxwwhFdxA05PXl7UqsyY9sLkpv+RVessbAtwzpZwLwNA= X-Received: by 2002:a17:902:d512:b0:156:b23f:ed62 with SMTP id b18-20020a170902d51200b00156b23fed62mr6252643plg.147.1649208179456; Tue, 05 Apr 2022 18:22:59 -0700 (PDT) MIME-Version: 1.0 References: <20220227120747.711169-1-ruansy.fnst@fujitsu.com> <20220227120747.711169-2-ruansy.fnst@fujitsu.com> <4fd95f0b-106f-6933-7bc6-9f0890012b53@fujitsu.com> <15a635d6-2069-2af5-15f8-1c0513487a2f@fujitsu.com> <4ed8baf7-7eb9-71e5-58ea-7c73b7e5bb73@fujitsu.com> <20220330161812.GA27649@magnolia> In-Reply-To: From: Dan Williams Date: Tue, 5 Apr 2022 18:22:48 -0700 Message-ID: Subject: Re: [PATCH v11 1/8] dax: Introduce holder for dax_device To: Jane Chu Cc: "Darrick J. Wong" , Christoph Hellwig , Shiyang Ruan , Linux Kernel Mailing List , linux-xfs , Linux NVDIMM , Linux MM , linux-fsdevel , david Content-Type: text/plain; charset="UTF-8" X-Stat-Signature: 8yrihrf3d7kq3uyp8wwa1tjnw7wkrgjr Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=intel-com.20210112.gappssmtp.com header.s=20210112 header.b=DTGX679O; dmarc=fail reason="No valid SPF, DKIM not aligned (relaxed)" header.from=intel.com (policy=none); spf=none (imf19.hostedemail.com: domain of dan.j.williams@intel.com has no SPF policy when checking 209.85.214.175) smtp.mailfrom=dan.j.williams@intel.com X-Rspam-User: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: 973E11A0007 X-HE-Tag: 1649208180-510803 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: On Tue, Apr 5, 2022 at 5:55 PM Jane Chu wrote: > > On 3/30/2022 9:18 AM, Darrick J. Wong wrote: > > On Wed, Mar 30, 2022 at 08:49:29AM -0700, Christoph Hellwig wrote: > >> On Wed, Mar 30, 2022 at 06:58:21PM +0800, Shiyang Ruan wrote: > >>> As the code I pasted before, pmem driver will subtract its ->data_offset, > >>> which is byte-based. And the filesystem who implements ->notify_failure() > >>> will calculate the offset in unit of byte again. > >>> > >>> So, leave its function signature byte-based, to avoid repeated conversions. > >> > >> I'm actually fine either way, so I'll wait for Dan to comment. > > > > FWIW I'd convinced myself that the reason for using byte units is to > > make it possible to reduce the pmem failure blast radius to subpage > > units... but then I've also been distracted for months. :/ > > > > Yes, thanks Darrick! I recall that. > Maybe just add a comment about why byte unit is used? I think we start with page failure notification and then figure out how to get finer grained through the dax interface in follow-on changes. Otherwise, for finer grained error handling support, memory_failure() would also need to be converted to stop upcasting cache-line granularity to page granularity failures. The native MCE notification communicates a 'struct mce' that can be in terms of sub-page bytes, but the memory management implications are all page based. I assume the FS implications are all FS-block-size based?