linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Jianfeng Wang <jianfeng.w.wang@oracle.com>
Cc: Michal Hocko <mhocko@suse.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm, oom: Add lru_add_drain() in __oom_reap_task_mm()
Date: Thu, 11 Jan 2024 13:54:04 -0800	[thread overview]
Message-ID: <20240111135404.609af4a26d0118c0d290f11c@linux-foundation.org> (raw)
In-Reply-To: <b2096bcb-bda6-4831-85a2-67759e783e4d@oracle.com>

On Thu, 11 Jan 2024 10:54:45 -0800 Jianfeng Wang <jianfeng.w.wang@oracle.com> wrote:

> 
> > Unless you can show any actual runtime effect of this patch then I think
> > it shouldn't be merged.
> > 
> 
> Thanks for raising your concern.
> I'd call it a trade-off rather than "not really correct". Look at
> unmap_region() / free_pages_and_swap_cache() written by Linus. These are in
> favor of this pattern, which indicates that the trade-off (i.e. draining
> local CPU or draining all CPUs or no draining at all) had been made in the
> same way in the past. I don't have a specific runtime effect to provide,
> except that it will free 10s kB pages immediately during OOM.

I don't think it's necessary to run lru_add_drain() for each vma.  Once
we've done it it once, it can be skipped for additional vmas.

That's pretty minor because the second and successive calls will be
cheap.  But it becomes much more significant if we switch to
lru_add_drain_all(), which sounds like what we should be doing here. 
Is it possible?



  reply	other threads:[~2024-01-11 21:54 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-09  9:15 [PATCH] mm, oom: Add lru_add_drain() in __oom_reap_task_mm() Jianfeng Wang
2024-01-10  8:46 ` Michal Hocko
2024-01-10 19:02   ` Jianfeng Wang
2024-01-11  8:46     ` Michal Hocko
2024-01-11 18:54       ` Jianfeng Wang
2024-01-11 21:54         ` Andrew Morton [this message]
2024-01-12  0:08           ` [External] : " Jianfeng Wang
2024-01-12  8:49             ` Michal Hocko
2024-01-12 21:43               ` Minchan Kim

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=20240111135404.609af4a26d0118c0d290f11c@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=jianfeng.w.wang@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).