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 06642C433EF for ; Mon, 11 Oct 2021 09:28:16 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A2C1B60F38 for ; Mon, 11 Oct 2021 09:28:15 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org A2C1B60F38 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 0BE9C6B0072; Mon, 11 Oct 2021 05:28:14 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 06ED5900002; Mon, 11 Oct 2021 05:28:14 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E9F936B0074; Mon, 11 Oct 2021 05:28:13 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0052.hostedemail.com [216.40.44.52]) by kanga.kvack.org (Postfix) with ESMTP id DC53A6B0072 for ; Mon, 11 Oct 2021 05:28:13 -0400 (EDT) Received: from smtpin38.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id 96D40181A88E4 for ; Mon, 11 Oct 2021 09:28:13 +0000 (UTC) X-FDA: 78683630466.38.388EE3D Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by imf18.hostedemail.com (Postfix) with ESMTP id 252D640039F0 for ; Mon, 11 Oct 2021 09:28:13 +0000 (UTC) Received: from relay2.suse.de (relay2.suse.de [149.44.160.134]) by smtp-out2.suse.de (Postfix) with ESMTP id BE3FF20047; Mon, 11 Oct 2021 09:28:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1633944491; 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=bzsf3qOeWL3PJZQYXdzcM4qU33SyWkAIXshFGPaeTMM=; b=ued5v0sFSNMVPRllyFCfLUKZ95H22GdIvG2tAhbnjyPI3mp3TUAeKsc9XsNJdUEzzjCM6j PYxNHl2RWLDc5JPVwu+LykQC/sMPkYOyX7LJNeBgTQIpHlLkb8QEyNhpnRFA+mG/CNkUtk e3Ot+kBeVmoBBjgTuQLpu2iIh6B11EA= 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 31155A3B8D; Mon, 11 Oct 2021 09:28:11 +0000 (UTC) Date: Mon, 11 Oct 2021 11:28:10 +0200 From: Michal Hocko To: David Hildenbrand Cc: ultrachin@163.com, akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, brookxu.cn@gmail.com, chen xiaoguang , zeng jingxiang , lu yihui , Claudio Imbrenda , Daniel Jordan Subject: Re: [PATCH] mm: Free per cpu pages async to shorten program exit time Message-ID: References: <20211008063933.331989-1-ultrachin@163.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 252D640039F0 X-Stat-Signature: dp3d8qhxhb6eoyzhgttmdror43e5x544 Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=suse.com header.s=susede1 header.b=ued5v0sF; dmarc=pass (policy=quarantine) header.from=suse.com; spf=pass (imf18.hostedemail.com: domain of mhocko@suse.com designates 195.135.220.29 as permitted sender) smtp.mailfrom=mhocko@suse.com X-HE-Tag: 1633944493-239602 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 Fri 08-10-21 10:17:50, David Hildenbrand wrote: > On 08.10.21 08:39, ultrachin@163.com wrote: > > From: chen xiaoguang > > > > The exit time is long when program allocated big memory and > > the most time consuming part is free memory which takes 99.9% > > of the total exit time. By using async free we can save 25% of > > exit time. > > > > Signed-off-by: chen xiaoguang > > Signed-off-by: zeng jingxiang > > Signed-off-by: lu yihui > > I recently discussed with Claudio if it would be possible to tear down the > process MM deferred, because for some use cases (secure/encrypted > virtualization, very large mmaps) tearing down the page tables is already > the much more expensive operation. > > There is mmdrop_async(), and I wondered if one could reuse that concept when > tearing down a process -- I didn't look into feasibility, however, so it's > just some very rough idea. This is not a new problem. Large process tear down can take ages. The primary road block has been accounting. This lot of work has to be accounted to the proper domain (e.g. cpu cgroup). A deferred and properly accounted context implementation is still lacking AFAIK. I have a vague recollection we have padata framework but I am not sure anybody has explored this to be used for the address space shutdown. IIRC Daniel Jordan was active in that area. -- Michal Hocko SUSE Labs