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 15DD7C004D4 for ; Thu, 19 Jan 2023 18:05:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 755A06B0071; Thu, 19 Jan 2023 13:05:37 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 7059F6B0073; Thu, 19 Jan 2023 13:05:37 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5A6F86B0074; Thu, 19 Jan 2023 13:05:37 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 49D566B0071 for ; Thu, 19 Jan 2023 13:05:37 -0500 (EST) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 1E8F2160DDD for ; Thu, 19 Jan 2023 18:05:37 +0000 (UTC) X-FDA: 80372326314.19.19CB3BC Received: from mail-pg1-f174.google.com (mail-pg1-f174.google.com [209.85.215.174]) by imf19.hostedemail.com (Postfix) with ESMTP id AAA541A0019 for ; Thu, 19 Jan 2023 18:05:33 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=VCALS7dr; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf19.hostedemail.com: domain of jiaqiyan@google.com designates 209.85.215.174 as permitted sender) smtp.mailfrom=jiaqiyan@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1674151533; 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=HhHe/vyWxnC7WfeTD96inBnE/GPgAKeDlOLWMb4tJzs=; b=bM6b7ENbtoDhlT0U+4CfNfmq9OF1AmQxZ+tjeJ1ruwTns9cicd9qg7Shw8GtJUHzrgRsbc dZ8RXwjDC5IqGSgCw5YrnfTexbDoeMEecYOu89zOvmn0zWz0JDVGXWDywBQa+PlMczY9MV LtZ37sTXqZ5Ybfsl/X/hpiZAIwKhde0= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=VCALS7dr; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf19.hostedemail.com: domain of jiaqiyan@google.com designates 209.85.215.174 as permitted sender) smtp.mailfrom=jiaqiyan@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1674151533; a=rsa-sha256; cv=none; b=ZVwkjk1OBtnzinb+smL1sZwO2gkRVYc+rX3rkSWf222bbVnWL6Qx7iVvu5kzXF7sJ3zFgZ WdD+5jo6C0R9424uWxKRq2UJjOUUR9lCcEf2v5go/+eu/G6HBDRQSfM3eyQw+px6qUXUI2 b2Oi52X2lma0Tl0ZaZwVrJxsxDQE1UI= Received: by mail-pg1-f174.google.com with SMTP id s67so2175539pgs.3 for ; Thu, 19 Jan 2023 10:05:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=HhHe/vyWxnC7WfeTD96inBnE/GPgAKeDlOLWMb4tJzs=; b=VCALS7dr8Fb+nzoUM5VGc6rhqY6EB1Rfx7g4ppS8U7v4EP2sRc0H2/3Tjb3Em1gZ7n UFp6BWz5cpcP0wxhiQ38GP5uO+nDXXEeTAVJ06erP5EhUWWFaw3lJ7dUN+EME+ThptMF L0w/PxGarkWO/rxONDIM6+cxdCqUxJcgEtQydwSZ7ORVsh/YTqEAlCmPW4yajFOJx3F9 Uy4u/qrIG6gAE23ieaPjoKqh2k82o4i72yql+tbDllV3VYPNopFm5+5/4A0+q5g8AotQ 9IYwrYSvp2gtvkDttSWgfC1kjPdGW7FsOhZefVAgRjdCo41mlUJwGvcqydK5Cy0Nc8jz UW1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=HhHe/vyWxnC7WfeTD96inBnE/GPgAKeDlOLWMb4tJzs=; b=JphOTy0UT2H/OSFbnlY+xJVoiuVZOV5w5b2E5zA3MqLCpy/KfUAeapHBIhplOabho8 UK7dSiJ79Xq4t9Zw1Q3puzaW8SVeZ/0Jvb58z0OxwdctN/buj70/3lTkz/l38OWFYVDN KSxxUO8wU4xOm6CLNn55fDWh2RPrB9COoHJ9icPvU/22skvHpTK8/BVY0dT+qTQ9g/0S L2CwfQEIE6B1rqoqJH3Xkkqex7OgcbAYHHyAgkBWxWPPRreWonfiWZ0uA9CQ9N/2Xl8P JmgUx2+byTPf+fY8vCkLs55iKrrnDweQU3Dq+x718xXo6bDWmjVMbLh8vmy7iWTNDN7j 8ojg== X-Gm-Message-State: AFqh2kqmAD/4giEEYPDMOioYRHevFNj0JO3gnY/d3rt/2ezIHuAHTAG/ YnOQNH/WImK/Wy9XZ4hrsBx4Onq2nBR7DFR7sQacAw== X-Google-Smtp-Source: AMrXdXut/Rvf5JFAgTHH3vQyLJbQLqN0jLbNAzaJx+LAMmfUDRFdDdTQjEmOfA0JvM1e+mCOPXcd8yEVonX114cJB84= X-Received: by 2002:a65:4d0f:0:b0:4a2:d7ef:2b9b with SMTP id i15-20020a654d0f000000b004a2d7ef2b9bmr1219048pgt.167.1674151532134; Thu, 19 Jan 2023 10:05:32 -0800 (PST) MIME-Version: 1.0 References: <20230116193902.1315236-1-jiaqiyan@google.com> <20230116193902.1315236-3-jiaqiyan@google.com> <20230116121613.234145e82988ca3e602dfce5@linux-foundation.org> <20230117090349.GB3428106@hori.linux.bs1.fc.nec.co.jp> <20230119064048.GA3516962@hori.linux.bs1.fc.nec.co.jp> In-Reply-To: <20230119064048.GA3516962@hori.linux.bs1.fc.nec.co.jp> From: Jiaqi Yan Date: Thu, 19 Jan 2023 10:05:20 -0800 Message-ID: Subject: Re: [PATCH v1 2/3] mm: memory-failure: Bump memory failure stats to pglist_data To: =?UTF-8?B?SE9SSUdVQ0hJIE5BT1lBKOWggOWPoyDnm7TkuZ8p?= Cc: Andrew Morton , "tony.luck@intel.com" , "duenwen@google.com" , "rientjes@google.com" , "linux-mm@kvack.org" , "shy828301@gmail.com" , "wangkefeng.wang@huawei.com" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspam-User: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: AAA541A0019 X-Stat-Signature: bh7uuqiijyrgmcjt877scxpjjh1z91r4 X-HE-Tag: 1674151533-333973 X-HE-Meta: U2FsdGVkX1+tisBmOF1sfp9A5xdD1GxiUEjWvBINfnoXzBpu+BAeRviEd3jWO6KMyLcXylTkpZvzFJgMwd85k8TcKNFe6FRgkiIX6QWuELzm4yImC7cHGaHixvwusF6X8BfZFVvikoBjq27Oqg8yAmeB5kjCl85ExSJo6rWiz5FHow+jpZIAKOOsjKR3M9YMuMiV+mziSWTaMg5pO7C7QBUFTJlfabc9GhiUgzoFg/AJBI64oAsULwtAE+ktYoO7nkjHi98586p9zrGlh3TGhZZCautpzvvR6mJMCRo6QjOFQo7aJHO/iP03TwM/AMAuWmTQ+i086oDzRUnbJWonVLABi6Fh/bmOoHv/5UeLxfLNPWfmMjnTJNqh5FmJnEL7zB5oH0ul4w9Zgjt5/MqupzDIs+On+NUV57VwwHF9TXxeBLoctmtUxpUfxfslkaEbJbmikGiaSfLUbSzrzdpTH+Ne+DapdkxFkXjt+woiswp29Y/uqE6qCzc4uZjFACtUEVWas3qBo+jGdQHsjY9vzOJ7cOo53j2im4Ie+Zxxgk7uMzOGcLgHVENZNsFeeY6kITG1tdFIRvOJ+IXjVBAkeP/JBwzXPkgdYY8AQ94sp3upTIjP6u1ddMbNBfRMUyB4AU23KJsnagOUPNX+puIB18dNqf/p93Qpp1xtIo+ARxgXaia8obugiEeWkVPOFQiV5StN5iBBLhtwbcaOsiBOiPX1imeKTim4GLd7jYG+Al5gCRT/ASJOSl1vBsCtbSTykuIBBVU8Txstp+NWM0NK3jqToSL2iWXKPxuPjXXgGb4E3bw94Wskv+5Wf2PdIxqNE9rOxJdfk8o8q60SkAfYd4acr2SBwWCgDMwoeYLspnwDYP6fw5Q+0SfBxcoyZcGQ0qMAemLDl2JOAdIUcfzFiaCUigfRpM90vWtHIbXai8C0KhVjmDdvMcV7/XdDsD41zqgrndGz+38Qd5XWONp tpJtPBtB DmXCcwoTS3iwOIL3hfazqR55TuNd274haxDUF7VdEi+0oZIH/x4QSCp7lfEznz3IPzNPuO7bxjX+75k/KAwagUYgQ3opP9IER6keQ 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: Oh, sorry I misunderstood, I thought you are suggesting introducing a new mutex for these counters. With the existing mf_mutex, I don't think atomic is really necessary. I will just leave them as unsigned long. Thanks for the clarification. On Wed, Jan 18, 2023 at 10:40 PM HORIGUCHI NAOYA(=E5=A0=80=E5=8F=A3=E3=80= =80=E7=9B=B4=E4=B9=9F) wrote: > > On Wed, Jan 18, 2023 at 03:05:21PM -0800, Jiaqi Yan wrote: > > On Tue, Jan 17, 2023 at 1:03 AM HORIGUCHI NAOYA(=E5=A0=80=E5=8F=A3=E3= =80=80=E7=9B=B4=E4=B9=9F) > > wrote: > > > > > > On Mon, Jan 16, 2023 at 12:16:13PM -0800, Andrew Morton wrote: > > > > On Mon, 16 Jan 2023 19:39:01 +0000 Jiaqi Yan = wrote: > > > ... > > > > > @@ -1227,6 +1227,39 @@ static struct page_state error_states[] = =3D { > > > > > #undef slab > > > > > #undef reserved > > > > > > > > > > +static void update_per_node_mf_stats(unsigned long pfn, > > > > > + enum mf_result result) > > > > > +{ > > > > > + int nid =3D MAX_NUMNODES; > > > > > + struct memory_failure_stats *mf_stats =3D NULL; > > > > > + > > > > > + nid =3D pfn_to_nid(pfn); > > > > > + if (unlikely(nid < 0 || nid >=3D MAX_NUMNODES)) { > > > > > + WARN_ONCE(1, "Memory failure: pfn=3D%#lx, invalid nid= =3D%d", pfn, nid); > > > > > + return; > > > > > + } > > > > > + > > > > > + mf_stats =3D &NODE_DATA(nid)->mf_stats; > > > > > + switch (result) { > > > > > + case MF_IGNORED: > > > > > + ++mf_stats->pages_ignored; > > > > > > > > What is the locking here, to prevent concurrent increments? > > > > > > mf_mutex should prevent the race. > > > > Since we are only incrementing these counters, I wonder if it makes > > sense to convert them into atomic_long_t (encapsulated inside > > memory_failure_stats) and do atomic_long_add, instead of introducing a > > struct mutex? > > I thought that all callers of action_result() (which is an only caller of > update_per_node_mf_stats()) are called with holding mf_mutex at the > beginning of memory_failure(), so the concurrent increments should not > happen on the new counters. But writing counters with atomic type/API is > fine to me. > > Thanks, > Naoya Horiguchi