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 13DCBC77B7C for ; Wed, 24 May 2023 15:58:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4CF9E900006; Wed, 24 May 2023 11:58:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 48034900003; Wed, 24 May 2023 11:58:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 34867900006; Wed, 24 May 2023 11:58:17 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 222C7900003 for ; Wed, 24 May 2023 11:58:17 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id A964DC0998 for ; Wed, 24 May 2023 15:58:16 +0000 (UTC) X-FDA: 80825605392.19.54555E5 Received: from mail-qv1-f53.google.com (mail-qv1-f53.google.com [209.85.219.53]) by imf13.hostedemail.com (Postfix) with ESMTP id 6CCBE2000F for ; Wed, 24 May 2023 15:58:13 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=cmpxchg-org.20221208.gappssmtp.com header.s=20221208 header.b=2VEdtsMc; dmarc=pass (policy=none) header.from=cmpxchg.org; spf=pass (imf13.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.219.53 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1684943893; 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=Lo1Bd8kQQKok6XtJWBuvliy13W3lA66R3FmWEDQGTs8=; b=DQm95PM4gTH+dJQwq0rnxyn05AUeihb8pQURkdQ1iBUE9JeybNSSKXHECJ6jzge486I8lz BzNLulOOmeCsVklCHxjsZtwCIvLsgcnwlP1sZr8icVtCHmCtgH40nrwQsTzuBiUSkuv3SE AS2rgvaGTb+7/jWSNd0rbQD3R225TvE= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=cmpxchg-org.20221208.gappssmtp.com header.s=20221208 header.b=2VEdtsMc; dmarc=pass (policy=none) header.from=cmpxchg.org; spf=pass (imf13.hostedemail.com: domain of hannes@cmpxchg.org designates 209.85.219.53 as permitted sender) smtp.mailfrom=hannes@cmpxchg.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684943893; a=rsa-sha256; cv=none; b=bIZOwIC/JOnptaSD2aPXMNKflju67cu54t1CL2bz+f7MJA4rp55cfUyh4xR8K9/jwbl98d btTudi4CWEHp5K7cemmPvaXKMhXhrGlvFAmFPpAMruFiD3AhNhnhVRlCnStkpwC0sS3MJE Ob5ix7JOtxOr2E5rVoi31ZFnD1IDB/0= Received: by mail-qv1-f53.google.com with SMTP id 6a1803df08f44-623a6c15aacso10013596d6.0 for ; Wed, 24 May 2023 08:58:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cmpxchg-org.20221208.gappssmtp.com; s=20221208; t=1684943892; x=1687535892; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=Lo1Bd8kQQKok6XtJWBuvliy13W3lA66R3FmWEDQGTs8=; b=2VEdtsMcvvWFefWeiXYVDgLPH8JWObDrEJKYw1yXU4atsvZ1jZ4qTM94DTLUYSLPHp XRgahDkBOLaIGTfz9hRXc1671KG4VLdjlEt3w8BoM2hu3Hdzx7DH9NS9oVfrYKzWgiYJ hhueoStgujR8NChqyj+y8GrXQPAx3dJEnJTiJ9F+pskcByaurrE18+DKRQBT+Lq3AcX/ OXQXsFOognFhXNzTyOaBQoE30ZVrwbE2aoKd8pVnpH2nnsosKJn/A6eH7WeLN2+zzMsT c63wQ/DnNCE2+Wg00CMsWEZvDURToZBhe1feccq7068rbO0Wlhyum/5ZK02njya7f5h+ lGoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684943892; x=1687535892; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Lo1Bd8kQQKok6XtJWBuvliy13W3lA66R3FmWEDQGTs8=; b=EFiCTnWIfMQzQPpGVdrjhE9ZQYtB7IRRhEllLlU9p9zCv3lskhzR/k4KjidO4PYG2T +HId9VPIP7Vw4q9uhE0AvtmzUPk8OXDmx548/OEmvv8Ck2wcci9clSZaap4w4pLN8lkU 57Ud3skQUScSxkjiPuW+9Dp3v0oqX1yuBGrqEyf0DaKcvf8lYc9IpyuhweznS26KTpJX OtRZfhJFlsWPKEJTRHkC5G3wzC5DYWXSan5xgEh1URE1GDk8L/zICgP310w97zpySWQm N2gSPx1/yT+xyr6PL0qccO/hw3wcWR+CNJq4jPJF9DDxXThIRVV02HRAb5I1+++YmAbW TrTA== X-Gm-Message-State: AC+VfDzXZnX9iWOpXSanVnt8NTJOFWYi7jbDgmpNiTSqrfDE+7kHBhgC SsRJGH3rGCDgl8lkJaT2O6rRmA== X-Google-Smtp-Source: ACHHUZ5PxIGt+Zc5ZcfzkXBmoWXbMEoEPZ8JoJKNs82T+X93QbJGrVVBdWsQ9j+GYYcm6SQrGhmtcg== X-Received: by 2002:a05:6214:c4e:b0:5ef:6eb6:e26e with SMTP id r14-20020a0562140c4e00b005ef6eb6e26emr26359735qvj.6.1684943892343; Wed, 24 May 2023 08:58:12 -0700 (PDT) Received: from localhost ([2620:10d:c091:400::5:8bb6]) by smtp.gmail.com with ESMTPSA id l16-20020a056214029000b0062168714c8fsm3642179qvv.120.2023.05.24.08.58.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 May 2023 08:58:11 -0700 (PDT) Date: Wed, 24 May 2023 11:58:11 -0400 From: Johannes Weiner To: Vlastimil Babka Cc: Andrew Morton , Mel Gorman , Michal Hocko , linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@fb.com Subject: Re: [PATCH] mm: compaction: avoid GFP_NOFS ABBA deadlock Message-ID: <20230524155811.GA14306@cmpxchg.org> References: <20230519111359.40475-1-hannes@cmpxchg.org> <8fd1a56d-5a22-4bde-59a5-169a4696219e@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8fd1a56d-5a22-4bde-59a5-169a4696219e@suse.cz> X-Rspam-User: X-Stat-Signature: a14ka7gu4f69enwfed5xb9dcsmcxqjeo X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 6CCBE2000F X-HE-Tag: 1684943893-327561 X-HE-Meta: U2FsdGVkX1+Nn6ruZCm4EuQezZ+0zM/6Rt2KhiEJb/Eyq9WZJxwezw1YY+8s31GNGD2Uinhn/aLjqZPqNsr9t77ObByKgpjMdWAtbR6hYA4vNhRD4mDmndrWEJhM4iHUd3m3zG31cweYRdOsEKksHGN6p5N/S44GTZcUxWLUtKgvkBTDLuV6r5Xa7TdNDlKIR5htwHwVAK5jQvWQQmYK3nUPnv26+Kui7MNG67iosG4QpMx2R/8TCeWvc2JUybsnSbdkkE0q4mqoPjkVL5BCFbdFjnihIQZJALR+Op2KVAhB6zITQei3oe7KsfoxUr4PrfP8lGtUB9ejKnVGOTgqpLRkRaVQGLymmwpTr0gWIsSod8GwM9NBOWyHKrsS6xlN7FsV9u2JfojK+J0otqIeFC3u1Nn6rl4DHU+dk0DZJ3HWDr+J1IgvYF9U81nJvkDqddh/Y2//Ivhu5Vn4c6XqPGS50W4OubXruJ92e1VTD9KMPEKRmV+jDH8owGJaUakMJKu9QwmQ/VSqjsu6SSKYdX6bnkPggjQLD49os/cEFrCRMDZ6XV32OmhXV/PRJm6sPzQZlR7cIdxPjOTDueuEf8FRkdd9YDtVV2WDdUv/Y7ZuBxdTlfXjSfBIZMwOpldx7YkPpI0fWx6TiCUTmdt/k4i4ZnUtuKjkO/K9i90GZkmNpjQkK/ubuBh5TEtEnhSxe3CqFgGmM3H68h20HrZ6ZPn8LA4a2wVhcvHFJMzPcAK/D81BwWgI5rxFfsFQk9RjWw7irVDgzc8X25s+766pgJdG26/dEVH3rAxoGNVxJHD3ETCaxmdzciVAqsk3lO7ndu7ZEkcZKgD+e8mLnZH1hBUPZQ627qYyZ9HvxF9T4NbmpzJ3nDpJqwShfPTTP6hRfxsI+oXhk1a69NPny0fT0GzXwX03Sn1Btm8ncrvZN+oY+a1BmtXDHw5/f2g8QgLxeaygFkpicLLj99e+7ei 6WW0gZgA bdYiDfxs3WyuBO1NjMLSvRzuXuX80gAzFJPgTktLaJvzGfuskuwBCovq7sa7FYSjMaVkaWU8O07944nJ6FnWUptoGNWvKpkN3clz/FL5dwFaw/qIjOs0dkwP8/igzZ4xzGPci8Cs3cKhs7dEUmONzlP8sjbkamAzr4LNqoikWEw/VrBT4jgZP7Otd5l6bVyyvhBPEeoNO6LzhOuUfOW52L933DMkn7QZ3kYaUU/W9EapUepsDG/OYnuVDZGFQW/0xW9G/5PYPXfcBnYBZrvGckK603weL8bduSFcSzlCRIwh9yQhs6jjJM+0tGtYX3gEfRNtJjj1Ijlb/erYFb5KTfH65orKKuA5Ii3iMvLBlSc2p/DoCvmdgMqrFjdYdzS1qs8/Q/V7jgA8ERtiCTGh2akb3TWSLfpl8PIMT2fCaau5tUKMJxwb2dpUAiyqoc9d6qimPLoRHO8YODtNgHWgvRBBK9frSCuMj1tVFDkiTMjcQ35luOwhVg6KvLaplbDqB0DssB8XcwJbV/EE= 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 Wed, May 24, 2023 at 11:21:43AM +0200, Vlastimil Babka wrote: > On 5/19/23 13:13, Johannes Weiner wrote: > > During stress testing with higher-order allocations, a deadlock > > scenario was observed in compaction: One GFP_NOFS allocation was > > sleeping on mm/compaction.c::too_many_isolated(), while all CPUs in > > the system were busy with compactors spinning on buffer locks held by > > the sleeping GFP_NOFS allocation. > > > > Reclaim is susceptible to this same deadlock; we fixed it by granting > > GFP_NOFS allocations additional LRU isolation headroom, to ensure it > > makes forward progress while holding fs locks that other reclaimers > > might acquire. Do the same here. > > > > This code has been like this since compaction was initially merged, > > and I only managed to trigger this with out-of-tree patches that > > dramatically increase the contexts that do GFP_NOFS compaction. While > > the issue is real, it seems theoretical in nature given existing > > allocation sites. Worth fixing now, but no Fixes tag or stable CC. > > > Signed-off-by: Johannes Weiner > > So IIUC the change is done by not giving GFP_NOFS extra headroom, but > instead restricting the headroom of __GFP_FS allocations. But the original > one was probably too generous anyway so it should be fine? Yes, the original limit is generally half the LRU, which is quite high. The new limit is 1/16th of the LRU for regular compactors and half for GFP_NOFS ones. Note that I didn't make these up; they're stolen from too_many_isolated() in vmscan.c. I figured those are proven values and no sense in deviating from them until we have a reason to do so. > Acked-by: Vlastimil Babka Thanks!