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 F3B92C433EF for ; Mon, 20 Sep 2021 20:32:16 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id D7DF861168 for ; Mon, 20 Sep 2021 20:32:16 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231163AbhITUdn (ORCPT ); Mon, 20 Sep 2021 16:33:43 -0400 Received: from smtp-out1.suse.de ([195.135.220.28]:53466 "EHLO smtp-out1.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231719AbhITUbl (ORCPT ); Mon, 20 Sep 2021 16:31:41 -0400 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: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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