Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp2373470pxb; Mon, 20 Sep 2021 20:33:24 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxnepzHki3A1e1cxevUZfrgmelrF3oSgpfrNoXhESg+r6qApxhvlndN2NogczWtLwosHnua X-Received: by 2002:a17:907:3e03:: with SMTP id hp3mr31651310ejc.183.1632195204313; Mon, 20 Sep 2021 20:33:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1632195204; cv=none; d=google.com; s=arc-20160816; b=x5Hz4YJ0j0w5CIFtd9ozJHQuNKPQcvQHoRmYUVvghRyJXrDKetYJH4vNXdWzagWtgV onShRX/j8UCS+THuGsxmWKijKIvmuwSzs3NA7FGl+od3jorpfAYPkfDuCL9pj4CQ23BY bQvrS/jWkvacoolnoEOhUnfPDxsnwWdnEbdK+jfjvoeU9oa2+uvlWdoJ3FLzygjAIZZz 63Ob5NTJgkE66Kb4V/s6QHkDsWB8365ebAfVlAaD1aXFRQRe3cZiOHKX2cUXeqITPiMI qhMQ0PauR9e6ayfyN0rbayvQDRZhNKfWZycNYbfxILHArZ1eNfTn2DOg3CDIfhyNXRaV Mraw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=BqPXGLxBTE8qoccsVMO4rB8AvTGsYllp8B25Awtj3T8=; b=qjysBbiDOzh40v+fRewFM4dZDgRc+8dM40yA6nH7HZeQbfkO1uEkJYvtkDO/WBdWky m+/riTgPOGAjHUGuAesPcoWZNV1iTgaE+y1FN4yHpEmQoFIOt28eo3x2ObZZBIa7QCdL VqLKU7ma6dhTfExjCsh/sSn6+YkHCIf4/koKY5aFoTN4gLkXhPHKtA7YabIfUPgh0y8s X+pB9G6WL8ul+6f8q+lGh22i7mngNgFBW7NJHoPerZzH1GKY9qGR5PEBdJBGQO6xiHcM QY9fW3dFdQ1GsT2wJ/BctZGWHm+B0uDTo4Pn9+j1+ke/GaoYA293al0+r9RaO6IO+xn4 6W4g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.com header.s=susede1 header.b=ijDkGCb1; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=suse.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id 3si19849213ejl.781.2021.09.20.20.33.01; Mon, 20 Sep 2021 20:33:24 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.com header.s=susede1 header.b=ijDkGCb1; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=suse.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230180AbhITUdm (ORCPT + 99 others); Mon, 20 Sep 2021 16:33:42 -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