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 73219C0219B for ; Wed, 12 Feb 2025 00:29:44 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 08EE76B0083; Tue, 11 Feb 2025 19:29:44 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 03F636B0085; Tue, 11 Feb 2025 19:29:43 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E6F5B6B0088; Tue, 11 Feb 2025 19:29:43 -0500 (EST) 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 C980E6B0083 for ; Tue, 11 Feb 2025 19:29:43 -0500 (EST) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 51BDFB1D69 for ; Wed, 12 Feb 2025 00:29:43 +0000 (UTC) X-FDA: 83109409446.15.2338A31 Received: from out-177.mta0.migadu.com (out-177.mta0.migadu.com [91.218.175.177]) by imf27.hostedemail.com (Postfix) with ESMTP id 8E0094000B for ; Wed, 12 Feb 2025 00:29:41 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=cLrGgEw7; spf=pass (imf27.hostedemail.com: domain of shakeel.butt@linux.dev designates 91.218.175.177 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1739320181; a=rsa-sha256; cv=none; b=OTtNDBU87NcFE6mw6CMxW75a0YFEtS4+VXMBTXHTxhRzupTrXLZagTw4N2vKP8ZzcMjOpD kfTpJ8r+GkOmFfU1KmfsuQmBc2revv9qqIJnsgS653KI+KnqmvnsL6NeT9wX0NiDotgV+3 V6b0LJXhnqMn+Wj18jOCR9sHRf7U3lM= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=cLrGgEw7; spf=pass (imf27.hostedemail.com: domain of shakeel.butt@linux.dev designates 91.218.175.177 as permitted sender) smtp.mailfrom=shakeel.butt@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1739320181; 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=2Qe89LtFFrDTAdD/f3HzKX0QL5OVcJ2KZ0CqRO/I52o=; b=m4dplfkNSpNMNOchhK86CZjm2rCsVoaK4iHlr9ZyoDI4JARec2bxyfmmRA9thwXAGmv1Nu /VjHUvUfiMHrAWDaUx/G4SJ6QmTiUW0vx+8X0G1YwFwEXxxMvzK6sEeI1CVmW6wQpE4gTB ijp8djtB37P6XVmotfpXhbpqHI2Ysf4= Date: Tue, 11 Feb 2025 16:29:32 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1739320179; h=from:from:reply-to:subject:subject: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=2Qe89LtFFrDTAdD/f3HzKX0QL5OVcJ2KZ0CqRO/I52o=; b=cLrGgEw7xHtISE4cNFN/zCLSIMPAt5jzelKswaFPczelMde5Uo+XWDR7Exry0QwvQXjcV3 nHjysNULme+ssxC2SLiQcQKkCxXBhfNn8MzYpBYV0H/zAh2/XI+BvrroJz0j4VXxqfkxCn 66BMWHAM4YyW+Dr7LVCFSW4zKIg8IVA= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Shakeel Butt To: Michal Hocko Cc: Chen Ridong , hannes@cmpxchg.org, roman.gushchin@linux.dev, muchun.song@linux.dev, akpm@linux-foundation.org, cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, chenridong@huawei.com, wangweiyang2@huawei.com Subject: Re: [PATCH] memcg: avoid dead loop when setting memory.max Message-ID: <24u7qp3ln2qaenzsdf6y4wimj4cbsylgs37ppex2jbq2hnonnv@m5hnbr7bz2t3> References: <20250211081819.33307-1-chenridong@huaweicloud.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Stat-Signature: b1jc53q3p5tomogb7kyam1m4makt8ma3 X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 8E0094000B X-Rspam-User: X-HE-Tag: 1739320181-347868 X-HE-Meta: U2FsdGVkX1+P9kq8LNYboIsQ4E2Y+u2uzsI7PPuyOqeEM/pgRUfL1Lzdf0+LdPfpKRZZOJywi4tLq2r4A9MBRI+Ut+aS0kwxatjP6YCVTRhNEzqxwPY6ukADCIYMYr/CgYcs4SWtT12o3GgvxbMgEst2KlGhHJGKjGh8WKJ42/9GDC/ssd1p++YkFwe/uTaPP8MTrlbsfzqQn7byEj2B5K30LkVVta5z3Ag8GHiqKQR5Ym2uWcmzbx4KNK/WOq2ih89fXqYjNsyd7OTfOlRAyMgf/BefvCtYzKbTjmC6khDirjmxguXzq3KNCfeYN+fzCLkmY9WwMPy5kabslQoE1rkETlXApCFYys5GCHD0gBjWeS++NPT3d3sWHrrvULkCWk4ZdXo/qWoTe4kaqDC20GRZiZT77apVF4g3Nlh/Sgd6hMpcbNFeFVwBqoQEMzKR8cNzP6BBFkfHlo4AhHow4XGkKiV3zptWU8vOXUENk+y5vm7kwR/FAomqV8YAqUBhVAqvPJZBZQJ9Y6MQRklQZgKZepx4CwpubiT35BaT3Zv0JAqmSad/IOzTqT96Ig+eEJp8ZiYmeJnNuvPvaoCkMhBWexQUev2Fl/Zar8Jq27hFIVdrKsJ+2WMDTVKK2HaNgh9FzHIwGHE874F6ZKlKU/ywCdObdCa1l+i6RiOzYOmlZYLB8IxmMkQ0ZYpbNd640jiPYaI7jwkOrnS4jRLPCj3dQyb2TJH1zitF0rUeh9GTS9Bvv857LbrNEuotFxyqXsh64fqPPLoD4Bv4SjUVBAR+26MwI0tRAVBvpWMUsTnFB5ULXDfZZNfPxTcpH9pQLpD6lQFv19stKcoqYRGvv5yX5XUasArJtmbe095s5NyQxLKxZhF44YnDy0oIBKv+LxRRFMMrja/4BryQzc/VIbOCYMRaENfjHJrHHvCeQ+HBD9FujY8lu5QL5fz6LTmsDZ+6Fa0QXAq7HW6JRjD GgR+xkdZ VUZLJwMe55br3tSjp373L+0gw9+HVRYdbhSvcmQCl+SJcWgzSQmPfN8GE3kdtW56tfdWGleH2ELDIX4oVgO15ggXSUrMWtCtbURqufBBc/ltYJpTgoPhtlO6UtLDTQeuE9yd+Tu6XQSfNdRqNR1jkZ7uDqyJTnUjnON8wWqslnAiPYbMsGYE7sB3xDQ== 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: List-Subscribe: List-Unsubscribe: On Tue, Feb 11, 2025 at 09:35:47PM +0100, Michal Hocko wrote: > On Tue 11-02-25 11:04:21, Shakeel Butt wrote: > > On Tue, Feb 11, 2025 at 08:18:19AM +0000, Chen Ridong wrote: > [...] > > Wouldn't it be more robust if we put an upper bound on the else case of > > above condition i.e. fix number of retries? As you have discovered there > > is a hidden dependency on the forward progress of oom_reaper and this > > check/code-path which I think is not needed. > > Any OOM path has a dependency on oom_reaper or task exiting. Personally I would say any allocation (or charge) has a dependency on oom_reaper making progress (but not arguing on this point). > Is there > any reason why this path should be any special? With cond_resched we can > look for a day where this will be just removed and the code will still > work. With a number of retries we will have a non-deterministic time > dependent behavior because number of retries rather than fwd progress > would define the failure mode. I am not against adding cond_resched() which might/will be removed in future. To me it is just that we are leaving our fate to cpu scheduler here which maybe is ok as we (MM) do it all over the place. Anyways no objection from me.