All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: Vlastimil Babka <vbabka@suse.cz>,
	ultrachin@163.com, akpm@linux-foundation.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org
Cc: brookxu.cn@gmail.com, chen xiaoguang <xiaoggchen@tencent.com>,
	zeng jingxiang <linuszeng@tencent.com>,
	lu yihui <yihuilu@tencent.com>,
	Claudio Imbrenda <imbrenda@linux.ibm.com>
Subject: Re: [PATCH] mm: Free per cpu pages async to shorten program exit time
Date: Fri, 8 Oct 2021 14:55:45 +0200	[thread overview]
Message-ID: <0ab1dd42-8869-5b41-3af5-e16a49335df2@redhat.com> (raw)
In-Reply-To: <8f30837b-5186-e836-21bc-9964456400c1@suse.cz>

On 08.10.21 14:38, Vlastimil Babka 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?

One use case I was told is that if you have a large (secure/encrypted) 
VM and shut it down, it might take quite a long time until you can 
actually start that very VM again, because tooling assumes that the VM 
isn't shut down until the process is gone (closed all files, sockets, etc.).

I also discussed the risk of OOM with Claudio. In some cases, we don't 
care, for example, we could start the VM on a different node in the 
cluster, or there is sufficient memory available to start it on the same 
node. But there was the idea to stop the OOM killer from firing as long 
as there is still some MM getting cleaned up, which would also make 
sense to some degree.

-- 
Thanks,

David / dhildenb


  parent reply	other threads:[~2021-10-08 12:55 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-08  6:39 [PATCH] mm: Free per cpu pages async to shorten program exit time ultrachin
2021-10-08  8:17 ` David Hildenbrand
2021-10-08  8:52   ` Claudio Imbrenda
2021-10-08  9:15     ` David Hildenbrand
2021-10-08  9:22       ` Claudio Imbrenda
2021-10-08  9:24         ` David Hildenbrand
2021-10-08 12:38   ` Vlastimil Babka
2021-10-08 12:54     ` Claudio Imbrenda
2021-10-08 12:55     ` David Hildenbrand [this message]
2021-10-10 22:42     ` Andrew Morton
2021-10-11  9:28   ` Michal Hocko
2021-10-11  9:40     ` David Hildenbrand
2021-10-11 11:23       ` Michal Hocko
2021-10-13 17:38     ` Daniel Jordan
2021-10-08 11:27 ` kernel test robot
2021-10-08 11:27   ` kernel test robot
2021-10-08 12:29 ` kernel test robot
2021-10-08 12:29   ` kernel test robot
2021-10-11  8:20 ` [mm] 3e55b36596: kernel_BUG_at_mm/page_alloc.c kernel test robot
2021-10-11  8:20   ` kernel test robot

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0ab1dd42-8869-5b41-3af5-e16a49335df2@redhat.com \
    --to=david@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=brookxu.cn@gmail.com \
    --cc=imbrenda@linux.ibm.com \
    --cc=linuszeng@tencent.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=ultrachin@163.com \
    --cc=vbabka@suse.cz \
    --cc=xiaoggchen@tencent.com \
    --cc=yihuilu@tencent.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.