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 X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9EC71C43331 for ; Thu, 2 Apr 2020 08:28:06 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 67862206F6 for ; Thu, 2 Apr 2020 08:28:06 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 67862206F6 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id CCCB38E0008; Thu, 2 Apr 2020 04:28:05 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C7C478E0007; Thu, 2 Apr 2020 04:28:05 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B918F8E0008; Thu, 2 Apr 2020 04:28:05 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0027.hostedemail.com [216.40.44.27]) by kanga.kvack.org (Postfix) with ESMTP id A018E8E0007 for ; Thu, 2 Apr 2020 04:28:05 -0400 (EDT) Received: from smtpin09.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 673398122 for ; Thu, 2 Apr 2020 08:28:05 +0000 (UTC) X-FDA: 76662237330.09.frog20_c55a2a26ea49 X-HE-Tag: frog20_c55a2a26ea49 X-Filterd-Recvd-Size: 3291 Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by imf22.hostedemail.com (Postfix) with ESMTP for ; Thu, 2 Apr 2020 08:28:04 +0000 (UTC) IronPort-SDR: XhcvSlEHfRrkygp7jvlAxAIMDQy/mgvvhxMnFwZc86F0nAyRelxhmVp/pxi6wjx34iZViHn0jS hIsETT8iUFtg== X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 02 Apr 2020 01:27:45 -0700 IronPort-SDR: pGB1j2C5kzFozFIrocpbQy+LXD3hj3RR/M30o46deo6Eymqej6TJxS9a16HNIqc0mRPKv9FHdi t6SsH6JEHzlQ== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.72,335,1580803200"; d="scan'208";a="449538056" Received: from yhuang-dev.sh.intel.com (HELO yhuang-dev) ([10.239.159.23]) by fmsmga005.fm.intel.com with ESMTP; 02 Apr 2020 01:27:40 -0700 From: "Huang\, Ying" To: Michal Hocko Cc: Andrew Morton , , , Zi Yan , Andrea Arcangeli , "Kirill A . Shutemov" , Vlastimil Babka , "Alexey Dobriyan" , Konstantin Khlebnikov , Jérôme Glisse , Yang Shi Subject: Re: [PATCH -V2] /proc/PID/smaps: Add PMD migration entry parsing References: <20200402020031.1611223-1-ying.huang@intel.com> <20200402064437.GC22681@dhcp22.suse.cz> <87zhbufjyc.fsf@yhuang-dev.intel.com> <20200402074411.GH22681@dhcp22.suse.cz> <87v9mifgui.fsf@yhuang-dev.intel.com> <20200402082142.GL22681@dhcp22.suse.cz> Date: Thu, 02 Apr 2020 16:27:37 +0800 In-Reply-To: <20200402082142.GL22681@dhcp22.suse.cz> (Michal Hocko's message of "Thu, 2 Apr 2020 10:21:42 +0200") Message-ID: <87lfnefg1y.fsf@yhuang-dev.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=ascii 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: Michal Hocko writes: > On Thu 02-04-20 16:10:29, Huang, Ying wrote: >> Michal Hocko writes: >> >> > On Thu 02-04-20 15:03:23, Huang, Ying wrote: > [...] >> >> > Could you explain why do we need this WARN_ON? I haven't really checked >> >> > the swap support for THP but cannot we have normal swap pmd entries? >> >> >> >> I have some patches to add the swap pmd entry support, but they haven't >> >> been merged yet. >> >> >> >> Similar checks are for all THP migration code paths, so I follow the >> >> same style. >> > >> > I haven't checked other migration code paths but what is the reason to >> > add the warning here? Even if this shouldn't happen, smaps is perfectly >> > fine to ignore that situation, no? >> >> Yes. smaps itself is perfectly fine to ignore it. I think this is used >> to find bugs in other code paths such as THP migration related. > > Please do not add new warnings without a good an strong reasons. As a > matter of fact there are people running with panic_on_warn and each > warning is fatal for them. Please also note that this is a user trigable > path and that requires even more care. OK for me. Best Regards, Huang, Ying