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 0E51DC77B75 for ; Mon, 22 May 2023 11:34:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A2ECB900003; Mon, 22 May 2023 07:34:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9B7EA900002; Mon, 22 May 2023 07:34:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8A6DF900003; Mon, 22 May 2023 07:34:21 -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 76BA1900002 for ; Mon, 22 May 2023 07:34:21 -0400 (EDT) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 426BBA026B for ; Mon, 22 May 2023 11:34:21 +0000 (UTC) X-FDA: 80817682722.13.44998DC Received: from www262.sakura.ne.jp (www262.sakura.ne.jp [202.181.97.72]) by imf08.hostedemail.com (Postfix) with ESMTP id 84056160011 for ; Mon, 22 May 2023 11:34:18 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=none; dmarc=none; spf=none (imf08.hostedemail.com: domain of penguin-kernel@I-love.SAKURA.ne.jp has no SPF policy when checking 202.181.97.72) smtp.mailfrom=penguin-kernel@I-love.SAKURA.ne.jp ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684755259; a=rsa-sha256; cv=none; b=OGCmQkCFaAmG8+9CteIgsP9/I2cFuW95jWNJpUR4cUWGklEGfY+Zl9WIl5wyu2wdfKKEPw fz1m33KsrnIaJH5O6L1VLWh2V7RGfo5PdvawowptB7kDB3ae7Lo5YID2Zqml5cGl5sD/OX KNH6FCuk+5KHaLoTlaqeDDv4Kwy9ZSU= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=none; dmarc=none; spf=none (imf08.hostedemail.com: domain of penguin-kernel@I-love.SAKURA.ne.jp has no SPF policy when checking 202.181.97.72) smtp.mailfrom=penguin-kernel@I-love.SAKURA.ne.jp ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1684755259; 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; bh=AYDtoh5mxqYqc6EDdsPzMeP0JarrQHBBAVQsSfkeDKQ=; b=gL0bK2PoPigYQOSu4myJs/AfNstu48heBc6Wp6jVMACNvWdNkPU5GdTK1PJ1dSj/pNFhBv 0ygklKHxyNiQ6yNg0+TtBK/IRS6dSQJ2bKXZmoJXyFD3LpvKmNhjWaAm+p/wPMrm2xkl2K RG/2IPUsDJi4Ic1NIY2A9JzlNWpEkm0= Received: from fsav315.sakura.ne.jp (fsav315.sakura.ne.jp [153.120.85.146]) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTP id 34MBXpNp050520; Mon, 22 May 2023 20:33:51 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) Received: from www262.sakura.ne.jp (202.181.97.72) by fsav315.sakura.ne.jp (F-Secure/fsigk_smtp/550/fsav315.sakura.ne.jp); Mon, 22 May 2023 20:33:51 +0900 (JST) X-Virus-Status: clean(F-Secure/fsigk_smtp/550/fsav315.sakura.ne.jp) Received: from [192.168.1.6] (M106072142033.v4.enabler.ne.jp [106.72.142.33]) (authenticated bits=0) by www262.sakura.ne.jp (8.15.2/8.15.2) with ESMTPSA id 34MBXpQF050517 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NO); Mon, 22 May 2023 20:33:51 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) Message-ID: Date: Mon, 22 May 2023 20:33:49 +0900 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Subject: Re: [PATCH] lib/stackdepot: stackdepot: don't use __GFP_KSWAPD_RECLAIM from __stack_depot_save() if atomic context Content-Language: en-US To: "Huang, Ying" Cc: syzbot , syzkaller-bugs@googlegroups.com, Mel Gorman , Vlastimil Babka , Andrew Morton , Alexander Potapenko , Andrey Konovalov , Dmitry Vyukov , Andrey Ryabinin , kasan-dev , linux-mm , Johannes Weiner , Michal Hocko 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> From: Tetsuo Handa In-Reply-To: <87a5xx2hdk.fsf@yhuang6-desk2.ccr.corp.intel.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 84056160011 X-Stat-Signature: k9kwad85tyuxjp45nsya4ifenbah8iki X-Rspam-User: X-HE-Tag: 1684755258-768652 X-HE-Meta: U2FsdGVkX1+62stGmoToDucN0q/0H8fKGu47upKe72p37k3QSHi1GYfZeR2eU0mRuKJd39pvyD63ZcpcJZAtjTce0PUfTMWzadrXWEDe3+ngyzFK7rFlRL5YKfmFqP3LyP1MkR7QhV2KzRZV/pMQByb34cu79Kr+eOlc8eDlzNXzZdpswcsNa+yMzbiDk3oesIyQmRwnUx0I1L4IWZDEYz6zDGFCwagGlwA6vxr0W4E3HzYxis7D71IMGcI2FY4zpaXX362PNRU5W8Ptm/xTZRzegbwIQvamPe2EazxYTA9se6WRDoD7UXino6wqWbqYQz9pCer3L6ZuGrMQQTDdsBHPZM1LhaBtT+VLElOBwa4gzo9Rpa34kjHNbhOjitqWXCd4cr7qlQD4UptimLMLk/0s4FOkYm8Ugx1Y26Qbk/knDROb4USs3lu92AVDxrJQwUzkfl+z/q3S8WsbFX6s282mwLK8d1tkt2va/2lImYaD69vjQK31RflGwiLd/Rr5EKbAmbItGEXm/rm3zcSBNfyiTaZ7eii1tzLzjsOjo7TP7tSZTZRjJdK153Zm3RrPr93q22J+0bc5/hH4q7AOwgB3JxRmpm0Pug89dtDugss+kHJ1tUhp+tGBB+F6nZLIOSdRUkKH52MAtGfbfWKHAEa1tisJ4EW9JNXNzUXhVIfRsVyQ8CewBFKQVSL8DoCPpUo25j4k+DHUYgBEbeJaMAUFS0oRMUWtjqjfIkmSMICemBHQEX3URPEPnX5NiHVQkzatvUZWk0D3iHWFBU32B8xcfIyJXTmtWnfhWXDqnkLGIpHcQgCwWx5cIVQfYy7FszKWH9OPcJkHZ8EwZaPSPDJmCuInlUBSixqwt27nC4Wl4GCE3Vo1GPzj47yt7MjeijATyzyDkSVPINDBl1265kLM6d/BptrTC/5ZdOkkm+dhKx9DHWrNH6Br/fH5VKCncLbpPK7987P/36o8m41 Wm+7QYFW 6I+DnFcHn3fNF0u9q2IUdYe+91Vh8xhAiph3uYYgyyt3/Kuur4Y2SAaRNaXkjckTBpfwapOfs2pyAYTtijUhcFz70cQmJqKZw+3z4AQo8ZAVye7HhtpEOuMxfDnDBEjHBbNVJ6hGU/Rw5mpG+31dzSLNN0SUgC9M/7GPUjBq1hvd5lpMOhjwKw+SOa68j1vNTbm9D9zI87Ja7EJ8iogs9K3pJCPhRYlqdwTpkRbPbBi0LK6p/JFTfmkMdMqW6dgHsD+QjwXCT+L1ZDdtDZgwyX5XvmJdvVTmwXOldWANOCJHWjMdaXWafBklPQM4YwyB+cs8kjkgDYXZRNdfL1JA9zZSWsEn2YsRVBKEMUJuoTBg+oF1hariFuPZiSXi1Uh/Ogsr4dLqYBIm3nG+UQLgAmmKf9qvHjsPyrJAdXmR0SCpkLPr5Vk4KAtgaoP0rOvsMZQVuAZ+l0h/uMNQ= 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 2023/05/22 12:07, Huang, Ying wrote: > Tetsuo Handa writes: > >> On 2023/05/22 11:13, Huang, Ying wrote: >>>> Any atomic allocation used by KASAN needs to drop __GFP_KSWAPD_RECLAIM bit. >>>> Where do we want to drop this bit (in the caller side, or in the callee side)? >>> >>> Yes. I think we should fix the KASAN. Maybe define a new GFP_XXX >>> (instead of GFP_ATOMIC) for debug code? The debug code may be called at >>> almost arbitrary places, and wakeup_kswap() isn't safe to be called in >>> some situations. >> >> What do you think about removing __GFP_KSWAPD_RECLAIM from GFP_ATOMIC and GFP_NOWAIT? >> Recent reports indicate that atomic allocations (GFP_ATOMIC and GFP_NOWAIT) are not safe >> enough to think "atomic". They just don't do direct reclaim, but they do take spinlocks. >> Removing __GFP_KSWAPD_RECLAIM from GFP_ATOMIC and GFP_NOWAIT simplifies locking dependency and >> reduces latency of atomic allocations (which is important when called from "atomic" context). >> I consider that memory allocations which do not do direct reclaim should be geared towards >> less locking dependency. > > 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. > >> In general, GFP_ATOMIC or GFP_NOWAIT users will not allocate many pages. >> It is likely that somebody else tries to allocate memory using __GFP_DIRECT_RECLAIM >> right after GFP_ATOMIC or GFP_NOWAIT allocations. We unlikely need to wake kswapd >> upon GFP_ATOMIC or GFP_NOWAIT allocations. >> >> If some GFP_ATOMIC or GFP_NOWAIT users need to allocate many pages, they can add >> __GFP_KSWAPD_RECLAIM explicitly; though allocating many pages using GFP_ATOMIC or >> GFP_NOWAIT is not recommended from the beginning... > >>>From performance perspective, it's better to wake up kswapd as early as > possible. Because it can reduce the possibility of the direct > reclaiming, which may case very long latency. My expectation is that a __GFP_DIRECT_RECLAIM allocation request which happened after a !__GFP_KSWAPD_RECLAIM allocation request wakes kswapd before future __GFP_DIRECT_RECLAIM allocation requests have to perform the direct reclaiming. > > Best Regards, > Huang, Ying >