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 mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id EB4A6C433F5 for ; Fri, 12 Nov 2021 10:15:55 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 884DB61027 for ; Fri, 12 Nov 2021 10:15:55 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 884DB61027 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 D80E16B0074; Fri, 12 Nov 2021 05:15:54 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D31476B0078; Fri, 12 Nov 2021 05:15:54 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C1F906B007B; Fri, 12 Nov 2021 05:15:54 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0041.hostedemail.com [216.40.44.41]) by kanga.kvack.org (Postfix) with ESMTP id B438D6B0074 for ; Fri, 12 Nov 2021 05:15:54 -0500 (EST) Received: from smtpin10.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 584CE77A61 for ; Fri, 12 Nov 2021 10:15:54 +0000 (UTC) X-FDA: 78799872228.10.0439B55 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by imf28.hostedemail.com (Postfix) with ESMTP id CC37B9000508 for ; Fri, 12 Nov 2021 10:15:53 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out1.suse.de (Postfix) with ESMTP id 51409218B8; Fri, 12 Nov 2021 10:15:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1636712152; 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=64DGNgNkV9O62ggKgIwdNVIPe762Yddi4NRbefxXFbg=; b=ZHEaa/iBgPCpEIxTmAJlxtFwIfeoSEv8YhOtFYT2/ymMrhOO0ON66hH4tzJwIR4zp1jfbB bDnfAdhhGQRu6fkv+i1UA2aMeWHJuID0LNHD8wVlpNE5FarxIq2NYGi/LL/Zaqr3c1gdrL UuV9OwIuvqVgVaTrCNnTv+rVtmpwW2E= 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 CCD2AA3B8D; Fri, 12 Nov 2021 10:15:51 +0000 (UTC) Date: Fri, 12 Nov 2021 11:15:51 +0100 From: Michal Hocko To: Claudio Imbrenda Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, thuth@redhat.com, frankja@linux.ibm.com, borntraeger@de.ibm.com, Ulrich.Weigand@de.ibm.com, heiko.carstens@de.ibm.com, david@redhat.com, ultrachin@163.com, akpm@linux-foundation.org, vbabka@suse.cz, brookxu.cn@gmail.com, xiaoggchen@tencent.com, linuszeng@tencent.com, yihuilu@tencent.com, daniel.m.jordan@oracle.com, axboe@kernel.dk, legion@kernel.org, peterz@infradead.org, aarcange@redhat.com, christian@brauner.io, ebiederm@xmission.com, tglx@linutronix.de Subject: Re: [RFC v1 0/4] Two alternatives for mm async teardown Message-ID: References: <20211111095008.264412-1-imbrenda@linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211111095008.264412-1-imbrenda@linux.ibm.com> X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: CC37B9000508 X-Stat-Signature: xmenfx3ppboqdo75ky1mr9qcqm55kqq7 Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b="ZHEaa/iB"; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf28.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.28 as permitted sender) smtp.mailfrom=mhocko@suse.com X-HE-Tag: 1636712153-132071 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 Thu 11-11-21 10:50:03, Claudio Imbrenda wrote: > This RFC series proposes two possible ways for enabling asynchronous mm > teardown. It would be great to describe an intended usecase here and also explain why the existing features do not allow the required functionality. Please also make sure to cc linux-api when adding a new user visible interface or changing a visible behavior of existing one. E.g. why cannot you simply create a process outside of the thread group yet share the mm with your task. Once the other process exits which you can detect then you just exit that process and do the finall clean up from that context? > The first approach, in patch 1, is simply to provide an arch hook in > exit_mm. This has no functional change for archs that don't explicitly > use the hook, and leaves the hard part to arch code (including > accounting, if any). This is just too vague but I have to say I am not really a fan of hooks that considerably change the existing behavior. > The second approach, in patches 2 to 4, adds a new syscall to allow an > mm to be asynchronously torn down in the context of another process > (similarly to how process_mrelease works). It also adds an OOM notifier > to prevent the OOM killer from killing processes while the teardown is > in progress. I have to say I do not like oom notifier part at all. You can have different sources of the OOM (memcg, cpusets or global oom). It is impossible to tell those appart in the notifier. Not to mention that memcg oom is explicitly avoiding notifiers altogether. -- Michal Hocko SUSE Labs