Thread (21 messages) 21 messages, 7 authors, 2021-07-09

Re: [PATCH 1/1] mm: introduce process_reap system call

From: Suren Baghdasaryan <surenb@google.com>
Date: 2021-06-30 19:06:53
Also in: linux-api, lkml

On Wed, Jun 30, 2021 at 12:00 PM Shakeel Butt [off-list ref] wrote:
On Wed, Jun 30, 2021 at 11:44 AM Suren Baghdasaryan [off-list ref] wrote:
quoted
[...]
quoted
quoted
quoted
+       /*
+        * If the task is dying and in the process of releasing its memory
+        * then get its mm.
+        */
+       task_lock(task);
+       if (task_will_free_mem(task) && (task->flags & PF_KTHREAD) == 0) {
task_will_free_mem() is fine here but I think in parallel we should
optimize this function. At the moment it is traversing all the
processes on the machine. It is very normal to have tens of thousands
of processes on big machines, so it would be really costly when
reaping a bunch of processes.
Hmm. But I think we still need to make sure that the mm is not shared
with another non-dying process. IIUC that's the point of that
traversal. Am I mistaken?
You are right. I am talking about efficiently finding all processes
which are sharing mm (maybe linked into another list) instead of
traversing all the processes on the system.
Oh, I see. I think that's a good idea but belongs to a separate patch
as an optimization for task_will_free_mem().
Thanks for reviewing and for good suggestions!
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help