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 X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CF7C8C433EF for ; Mon, 20 Sep 2021 20:30:16 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 6F8D861168 for ; Mon, 20 Sep 2021 20:30:16 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 6F8D861168 Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id C25996B0071; Mon, 20 Sep 2021 16:30:15 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BD5066B0072; Mon, 20 Sep 2021 16:30:15 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A9C9D900002; Mon, 20 Sep 2021 16:30:15 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0251.hostedemail.com [216.40.44.251]) by kanga.kvack.org (Postfix) with ESMTP id 96FD36B0071 for ; Mon, 20 Sep 2021 16:30:15 -0400 (EDT) Received: from smtpin11.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 5398A82499A8 for ; Mon, 20 Sep 2021 20:30:15 +0000 (UTC) X-FDA: 78609093990.11.4A1CA41 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf25.hostedemail.com (Postfix) with ESMTP id E200FB000185 for ; Mon, 20 Sep 2021 20:30:14 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id 9CCFC21DF7; Mon, 20 Sep 2021 20:30:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1632169813; 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=BqPXGLxBTE8qoccsVMO4rB8AvTGsYllp8B25Awtj3T8=; b=ijDkGCb15uUNE6To4BOCCB+9rkupV1KEgJf5DHafl2WXLO9CqsTq3Khkt9ihhfa2YepUE1 VxoBfzgvS8hdZFcwhOjY8jw95/L1BU33VYNiT++jDHdjboDuDi8eQP7K9WxBXYTzhYcLE6 h8tftd7o73eNusxrtA8tQJw2qdGMKhY= Received: from suse.cz (unknown [10.100.201.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by relay2.suse.de (Postfix) with ESMTPS id 64D9FA3B99; Mon, 20 Sep 2021 20:30:13 +0000 (UTC) Date: Mon, 20 Sep 2021 22:30:12 +0200 From: Michal Hocko To: Sultan Alsawaf Cc: Andrew Morton , David Rientjes , Mel Gorman , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm: Mark the OOM reaper thread as freezable Message-ID: References: <20210918233920.9174-1-sultan@kerneltoast.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=ijDkGCb1; spf=pass (imf25.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com X-Stat-Signature: x4kkbnarziaznmhrnaiwfreorr345jc7 X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: E200FB000185 X-HE-Tag: 1632169814-210440 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 20-09-21 12:16:39, Sultan Alsawaf wrote: > On Mon, Sep 20, 2021 at 07:34:26PM +0200, Michal Hocko wrote: > > The intention and the scope of the patch should be in the changelog. > > Your Fixes tag suggests there is a problem to fixed. > > I guess References would be more appropriate here? I'm not familiar with every > subsystem's way of doing things, so I just rolled with Fixes to leave a > breadcrumb trail to the original commit implicated in my change. What would you > suggest in a case like this for mm patches? We usually tend to provide Fixes where there has been something fixed. It seems just confusing if it is used for non functional changes, cleanups etc. Thera are gray zones of course. > > My memory has faded but I suspect it was to make sure that the oom > > reaper is not blocking the system wide freezing. The operation mode of > > the thread is to wait for oom victims and then do the unmapping without > > any blocking. While it can be frozen during the operation I do not > > remember that causing any problems and the waiting is exactly the point > > when that is obviously safe - hence wait_event_freezable which I believe > > is the proper API to use. > > This isn't clear to me. Kthreads come with PF_NOFREEZE set by default, so the > system-wide freezing will already ignore the reaper thread as-is, although it > will make that determination from inside freeze_task() and thus > freezing_slow_path(), which involves acquiring a lock. You could set > PF_FREEZER_SKIP to skip the slowpath evaluation entirely. I am not sure I follow. My understanding is that we need to make sure oom_reaper is not running after the quiescent state as it is changing user space address space. For that I believe we need to freeze the kthread at a proper moment. That is currently the entry point and maybe we can extend that even to the reaping loop but I haven't really explored that. PF_FREEZER_SKIP would skip over the reaper and that could result in it racing with the snapshotting no? > Furthermore, the use of wait_event_freezable() will make the reaper thread enter > try_to_freeze() every time it's woken up. This seems wasteful considering that > the reaper thread will never actually freeze. Is this something to really worry about? -- Michal Hocko SUSE Labs