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 C1006C77B75 for ; Tue, 23 May 2023 01:11:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4DC07280001; Mon, 22 May 2023 21:11:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4647E900003; Mon, 22 May 2023 21:11:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3055F280001; Mon, 22 May 2023 21:11:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 1C669900003 for ; Mon, 22 May 2023 21:11:32 -0400 (EDT) Received: from smtpin29.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id DDA9BC03BC for ; Tue, 23 May 2023 01:11:31 +0000 (UTC) X-FDA: 80819741982.29.4163FA7 Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by imf11.hostedemail.com (Postfix) with ESMTP id BFCAA4000A for ; Tue, 23 May 2023 01:11:28 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=jFeNWzpH; spf=pass (imf11.hostedemail.com: domain of ying.huang@intel.com designates 192.55.52.120 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1684804289; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=C6RfMwDzarbcKVcCAAmlwwn9MSUBhRls1C47MYjQR+M=; b=LHEllgINfNAeoqSHuNZAe025NTmGfhM9SNpvliVoQq1sDSq3g1gEBInujV5Rh9vFGA4ouM m/0xkBGe3/1b0NNHX3BoYQbQu6N9bjYDZYbL0ycpgb/HCoBkU6PRlhMftfkKIgNGwr3/94 wk249ebavlL8nFW+w6ntOnrY4+slEOg= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684804289; a=rsa-sha256; cv=none; b=iL24Ac0KLoxl5MLrwjgA954eGaqtx/PJBte7qDJsuvOpUowW21KQpaDfpYFOk4MO+gCz4x RMkTZTT53wBHBYsnU4zSZoMJ2esDsORX2Mlhx632S6gSbSzo4QIsO1BKkPsrGUjm4MIfCb TVw/fvYNzQ1AgLUuCtIViUoJZWrTHLI= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b=jFeNWzpH; spf=pass (imf11.hostedemail.com: domain of ying.huang@intel.com designates 192.55.52.120 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1684804288; x=1716340288; h=from:to:cc:subject:references:date:in-reply-to: message-id:mime-version; bh=I3Ub6Hl3YsYECiWMpbz/LI9yWctIyWSRO4gjJcgmSl0=; b=jFeNWzpHcVEdCfz5mfIWMLLNLsR7Jbdx4VDR5ZCPNVU9b237Cp8c85Ib /fDJVdBS7YKPN63a8Wr6I9ciN1yjqywEfaO0/ayf9CE07Xox5WCiLXwbk 97iK8Dya4zHh8p55sNjYyEQMtY5MmTCPEQxxhptTwEAy6wVl9ZopcnMT/ 96BoLiuneTIumIEgaOH+/I81GSFZ9gFR+MEi2rxgXuoCPFrcd8pcQIhcH u0NTKylbhsji+05QWfyuYh+FO8vd+Socr/9dY76EAGI26I2QSQ/XbKLcM DOxfERjwMxYzvoFNwXiKDy1oK9/hix2OygzD1eSUbuL6l1z8F07f4ZOt8 A==; X-IronPort-AV: E=McAfee;i="6600,9927,10718"; a="351937612" X-IronPort-AV: E=Sophos;i="6.00,184,1681196400"; d="scan'208";a="351937612" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga104.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 May 2023 18:11:26 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10718"; a="734559964" X-IronPort-AV: E=Sophos;i="6.00,184,1681196400"; d="scan'208";a="734559964" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 May 2023 18:11:23 -0700 From: "Huang, Ying" To: Tetsuo Handa Cc: syzbot , , Mel Gorman , Vlastimil Babka , Andrew Morton , Alexander Potapenko , Andrey Konovalov , Dmitry Vyukov , Andrey Ryabinin , kasan-dev , linux-mm , Johannes Weiner , Michal Hocko Subject: Re: [PATCH] lib/stackdepot: stackdepot: don't use __GFP_KSWAPD_RECLAIM from __stack_depot_save() if atomic context References: <000000000000cef3a005fc1bcc80@google.com> <48a6a627-183d-6331-0d8d-ae4b1d4b0101@I-love.SAKURA.ne.jp> <9c44eba9-5979-ee78-c9c8-626edc00f975@I-love.SAKURA.ne.jp> <87edn92jvz.fsf@yhuang6-desk2.ccr.corp.intel.com> <0471c62b-7047-050a-14f5-f47dfaffaba7@I-love.SAKURA.ne.jp> <87a5xx2hdk.fsf@yhuang6-desk2.ccr.corp.intel.com> <871qj7zz8z.fsf@yhuang6-desk2.ccr.corp.intel.com> Date: Tue, 23 May 2023 09:10:20 +0800 In-Reply-To: (Tetsuo Handa's message of "Tue, 23 May 2023 09:45:02 +0900") Message-ID: <87fs7nyhs3.fsf@yhuang6-desk2.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=ascii X-Rspamd-Queue-Id: BFCAA4000A X-Rspam-User: X-Stat-Signature: b3yzb7cby37gf7ajba1cnt3htp573ctj X-Rspamd-Server: rspam03 X-HE-Tag: 1684804288-834914 X-HE-Meta: U2FsdGVkX18sBS3JHr8YoLcpW9bUyEvXnhH9OTAcD+fOC/cnt8I84llgHM2wsjRifZw+0yOBjKkpVBm/jABHw4znlAQwHSETWqd+stqBadNrtbU6i7CDD1KFpCcRcvQHr/FkVsSQx1aYzeS4WWi4Qy30Kz/Z3kHQEb+q7AKw8TPj4ho3YG2W39umi+U4bGUBbn1XdfSAoUAUWGLUCHGZf1zkHyuu10aCuptluLmtcs3Af3YXUK12LLzvvRlZx/oH5Ba0Tu6n1lta9tBi99fCyJtsX+wOoztEtfPQGgcv5KSrcPQYmC/XUpGiqIRQ2sN0ZQ9g6z3cZzdrww/1WhMhReb+WqqRlahulbCTb4OGdadaSkMafDWhBds/XkW+NxB0l13IRwqYsL8EfBgpjLD5J0Rnp8s1vmNfnbZWsUM5GVN9AvsMbkeQOLML8jRkmnabSZRmCgr/OtceAaHaisB4jNequnfy2qRWBDi1IqD8ZxYPkX+UtQs6Yt7cMaEwIfvVnPPQedvM2m94LTlcfop+hEDDN2NFniY7SPWGvVjcl0jvsqV5nVpb1tZY4dtpFr6khAHELRd6N+Xip8x/uGkvxRQKZ0Y9QaI+9m7Rjs+t/xU+8WUBa9+IBJzhzDWStd7x6dYcjv480YegbGxnjlI0a+6hrZ58w71eRYUOc5Vve4d5EdcWikP9vvcyrtOvcg1a1CRbzQ5c92hHEfHwgfLG63OWRtE8C+RIDtBYXbsddEL4UJ7V62paR+5ifQSFpOlq/+zHUPRqnUMefMgh8t6TAIR9FE7i/Pz7qhBIEM/JA06huU0ToddBZI6/7G1ZoOECPh+0hu2g096QCmmrX0vthFcpPGCcXb8W4VPlx5wxjMkTe6ZnlGec8y+bp5fAoTm+cFCVSoTvqL6wdoIUthoNgrhj0P7AgKxj8I+/zh9RPG4EUpvM3HSxzX/Z5vSKnI3WvVc+f3VLayPZrIZtyUe 3n3R0uY6 TftzDxpXmTTKUmSXIe1l7fkcR4HO1OWfjN5VXHKPj4Glj9farIguZF1Zn4JqRf4x2jA/lfZxfKfv3SNXEsufdoAlmk2irOMe3wV2wL3c9twFNL7gD2KoNHFI3eAUvXWU9GPX4/Z4bR9Tlm6+1s3tDoAewdLLLG7Js5EF44KDQ9VkTwog9gTtodcJRlGYILQNLC+gBTUXSJqu7ZBJvnYDVFlkjVYAmJzEXt0r4XOHUvV6cJwH5+cIA77JJKvwi4GXZ1OOfd6gGlG0IIIasrdTuhDiCGLzOMFL0Yr3pbT9RLyUjDLT59PgHH/oggE04imCodXIwZYaudleJI08YDoAf+FT3Sgb7OAgcOnCQ 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: Tetsuo Handa writes: > On 2023/05/23 9:07, Huang, Ying wrote: >>>> Except debug code, where do you find locking issues for waking up kswapd? >>> >>> I'm not aware of lockdep reports except debug code. >>> >>> But due to too many locking dependency, lockdep gives up tracking all dependency (e.g. >>> >>> https://syzkaller.appspot.com/bug?extid=8a249628ae32ea7de3a2 >>> https://syzkaller.appspot.com/bug?extid=a70a6358abd2c3f9550f >>> https://syzkaller.appspot.com/bug?extid=9bbbacfbf1e04d5221f7 >>> https://syzkaller.appspot.com/bug?extid=b04c9ffbbd2f303d00d9 >>> >>> ). I want to reduce locking patterns where possible. pgdat->{kswapd,kcompactd}_wait.lock >>> and zonelist_update_seq are candidates which need not to be held from interrupt context. >> >> Why is it not safe to wake up kswapd/kcompactd from interrupt context? > > I'm not saying it is not safe to wake up kswapd/kcompactd from interrupt context. > Please notice that I'm using "need not" than "must not". Got it. > Since total amount of RAM a Linux kernel can use had been increased over years, > watermark gap between "kswapd should start background reclaim" and "current thread > must start foreground reclaim" also increased. Then, randomly allocating small > amount of pages from interrupt context (or atomic context) without waking up > will not needlessly increase possibility of reaching "current thread must start > foreground reclaim" watermark. Then, reducing locking dependency by not waking up > becomes a gain. Personally, I prefer to wake up kswapd ASAP. And fix the deadlock if possible. Best Regards, Huang, Ying