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 65ECAC7EE23 for ; Wed, 24 May 2023 12:10:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EC31A6B0074; Wed, 24 May 2023 08:10:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E73746B0075; Wed, 24 May 2023 08:10:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D1418900002; Wed, 24 May 2023 08:10:04 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id BF1736B0074 for ; Wed, 24 May 2023 08:10:04 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 57AE6AE42E for ; Wed, 24 May 2023 12:10:04 +0000 (UTC) X-FDA: 80825030328.12.B786526 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf09.hostedemail.com (Postfix) with ESMTP id 48A6414001F for ; Wed, 24 May 2023 12:10:01 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=iwA8pBLj; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf09.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1684930202; 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=zLYVfPUqC5itE9Z1gpOugKKlSVBzS5/R2EGbMjp6o2k=; b=N0UY0KJD2mcSje5mx+mWHXqURQ2XAe5zlVXrDBVE0CW0SB8J0b2hCVdGyxlydbJ97BVypn FjG4XpZKRr8hPRcrrmBZ+1nhDxGuVC2uzE/7Gm52hmcQFetuA+Oi+BFfHajoneY3B+/4Vd fL7b/LnUT362ytkV8CAMFKYeMT99IYw= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=iwA8pBLj; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf09.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684930202; a=rsa-sha256; cv=none; b=dQ3LDpINWdgfcAs3C1OL4xSbYOROZX4+iM/PtjhofdSS137WfH52++nhA4wx4ciiuF+v61 QHQhU7UAWHyrZbkCNUhlwHoJ6pONr1mG8ZgzqdlMk3prMd2k8E2HDTSrB4ycX6acg0Pga9 iGyI6fKH+F6z0HJwHUbPgx95kTwoV2g= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id A8C561F8B6; Wed, 24 May 2023 12:10:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1684930200; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=zLYVfPUqC5itE9Z1gpOugKKlSVBzS5/R2EGbMjp6o2k=; b=iwA8pBLjlsczw0PtWjcv/I3onQW9MHxIy5fhTu1vx+dhrnCJXrAH9spdqdmPhhj/AvxkG+ Zamqh7VPpg6RXqXSVJX5eZUkFKZMB8S1WhdrZ0k6H2YNMio9C847eRGVUIzaM53xHdQAgY 3UXAlSx9mLGG+yE/IMtfgiFRexPkYQY= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 898C913425; Wed, 24 May 2023 12:10:00 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id UTa0Hpj+bWSAXQAAMHmgww (envelope-from ); Wed, 24 May 2023 12:10:00 +0000 Date: Wed, 24 May 2023 14:09:59 +0200 From: Michal Hocko To: Tetsuo Handa Cc: "Huang, Ying" , 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 Subject: Re: [PATCH] lib/stackdepot: stackdepot: don't use __GFP_KSWAPD_RECLAIM from __stack_depot_save() if atomic context Message-ID: 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0471c62b-7047-050a-14f5-f47dfaffaba7@I-love.SAKURA.ne.jp> X-Rspam-User: X-Stat-Signature: mzt1ka45dde5gzh86qfz3qfopqdntoux X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 48A6414001F X-HE-Tag: 1684930201-486615 X-HE-Meta: U2FsdGVkX18kK97qnBY18nlZCdO4SXWJjHgZdLY1W82GJCJT/ISch+rsdUV3/qIp1jOpynGvuxqp1465UiUDtiyT0IpPWeIV0Dx+9nKGyz4VPa9pVCZEcK2RcSoVhOexovGZKM2PzWQ0g9DVZY1MVcNJHLrnbQYO3MPfqLTEzEu3pfpC/Nya0QeekHK2YRoeyVdsm9IxdjX2MbrITTXd774GAAbN/Z9UV4tZYf7go7xkEqSCy2xjTblmviDaMNd0BrO9F3Bkv/WM0JTg8l/F37KBbrvZXod162WZd8iyqAxV6gmirG4m9sE0u1yfGwYI7HB1Ug1zF0mcZ4LQmEflw/GDLKlLMSAB+c1B4W6sRD6qFM+l+D6teHYT9QRMlG3dJGvXGPlclgmUAM6ICCfbtgsYnITgfLZ+OBZgfGnDvsuimy+sp/w2FpK8j5Gvl12Cwq91MFHiTboL3MygXgecj3UCtydsEBQJ6ntuYeC8NAzbAxREAD+ZKIU0M1/fx2emPS9HGZwMkO3zp2rzTEl56qqA464PDv6D+lgDf6J2F5ISmXQUMNg83HWHtVa5no3GWIx4n9RXshGQGj4hG8sa5owurn5+HzhICEvWpqbVjbunpUZjK1SMIltE6pIJohQGRitQbPPId5z9xQNOn+9KKbhunTS1Lu+1SvAcGWaok2cjz3+6GaO2lhopcKMxeOokxLghGX6pDSW8RaaAv5IP9nUrs6hNYcjtYlYlxfqkJN8hKD1lxfL306ewQ75vzSi6lUZcEhP36NXTsXotgSXSCGvoeliQ+3dfq8lnueCwoQ3JGwRmlrOs1yhWJwjth/WNmwyaq7fMqjOcnGoKEStO3Ia8dGrmxc9ehWvQI9hdbKsiTKxImVo6P6nKFk7bsWqPQeMJP7L4ro6skJf4Q8M6ann9M8jQr45TGt1WjTpx6CdOeSAex0ZP+qg+DSllympdGpEhYRhp+KPu1iHVgqg rrI7zrtz GoFrR2dGesDQ0tlLpAtdGhzUF0lV6Fpci7fpaPsEgiPkd4WBju9xeD9NfV4smB06ejZDvjPDodT78qsM4u5fCxfbtalYP3ZlF7YFqU4Teq0GHwohqT4pR0S0CrPP16l52ogPA2nq/KPAUgRHmVi4oC/ZCXY506am1GXxRWmjbrDsyrIJYvLFp5LB0gRhTH9JJnSpYfm+SwgYZkuIJch3p07Y2ColT6PIM1Fcd/GDlXBSIcTD/0ruF9jUm/fYpJgFctGtnlfaCbh0HvigN8b+cu+GEUezEUWFajj3lmSrTdDQMjDk= 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 Mon 22-05-23 11:47:25, Tetsuo Handa wrote: > 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? Not a good idea IMO. It is really hard to achieve real locklessness in the page allocator. If we ever need something like that it should be pretty obviously requested by a dedicated gfp flag rather than overriding a long term established semantic. While GFP_ATOMIC is a bit of a misnomer it has many users who really only require non-sleeping behavior. > 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 would really like to see any numbers to believe this is the case actually. Waking up kswapd should be pretty non-visible. > I consider that memory allocations which do not do direct reclaim should be geared towards > less locking dependency. > > In general, GFP_ATOMIC or GFP_NOWAIT users will not allocate many pages. This hugely depend on the workload. I do not think we can make any generic statements like that. > 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. The thing is that you do not know this is a the case. You might have a IRQ heavy prossing making a lot of memory allocations (e.g. networking) while the rest of the processing doesn't require any additional memory. > 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... As much as I do not really like the long term GFP_ATOMIC semantic I do not think we should be changing it to what you are proposing for reasons mentioned above. GFP_NOWAIT change is even more questionable. Many users simply use GFP_NOWAIT as a way of an optimistic allocation with a more expensinsive fallback. We do not want to allow those consumers to consume watermark gap memory to force others to hit the direct reclaim wall. Really there is very likely only a handfull of users who cannot even wake kswapd or perform other non-sleeping locking and those should currently drop __GFP_KSWAPD_RECLAIM. Maybe we should consider an alias for them to not bother with the low level flag. Maybe we will need GFP_LOCKLESS or something similar. -- Michal Hocko SUSE Labs