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;
Date:   Fri, 8 Oct 2021 14:54:12 +0200
From:   Claudio Imbrenda <imbrenda@linux.ibm.com>
To:     Vlastimil Babka <vbabka@suse.cz>
Cc:     David Hildenbrand <david@redhat.com>, ultrachin@163.com,
        akpm@linux-foundation.org, linux-mm@kvack.org,
        linux-kernel@vger.kernel.org, brookxu.cn@gmail.com,
        chen xiaoguang <xiaoggchen@tencent.com>,
        zeng jingxiang <linuszeng@tencent.com>,
        lu yihui <yihuilu@tencent.com>
Subject: Re: [PATCH] mm: Free per cpu pages async to shorten program exit
 time
Message-ID: <20211008145412.20cbd312@p-imbrenda>
In-Reply-To: <8f30837b-5186-e836-21bc-9964456400c1@suse.cz>
References: <20211008063933.331989-1-ultrachin@163.com>
        <d71e6021-777b-3ca9-b08f-64fe7ff51e08@redhat.com>
        <8f30837b-5186-e836-21bc-9964456400c1@suse.cz>
Organization: IBM
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Precedence: bulk

On Fri, 8 Oct 2021 14:38:15 +0200
Vlastimil Babka <vbabka@suse.cz> wrote:

> On 10/8/21 10:17, David Hildenbrand wrote:
> > On 08.10.21 08:39, ultrachin@163.com wrote:  
> >> From: chen xiaoguang <xiaoggchen@tencent.com>
> >>
> >> 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 <xiaoggchen@tencent.com>
> >> Signed-off-by: zeng jingxiang <linuszeng@tencent.com>
> >> Signed-off-by: lu yihui <yihuilu@tencent.com>  
> > 
> > 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.  
> 
> OK, but what exactly is the benefit here? The cpu time will have to be spent
> in any case, but we move it to a context that's not accounted to the exiting
> process. Is that good? Also if it's a large process and restarts
> immediately, allocating all the memory back again, it might not be available
> as it's still being freed in the background, leading to a risk of OOM?

I argue that it is good, at least in some cases.

Depending on the type of process shutting down, restarting it
immediately might still be slow enough that no OOM condition will
arise.

and those are the reasons of the per-arch hook to determine when it
makes sense to do things asynchronously.

> 
> > 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.
> >