From: "Uladzislau Rezki (Sony)" <urezki@gmail.com>
To: Matthew Wilcox <willy@infradead.org>,
Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org
Cc: LKML <linux-kernel@vger.kernel.org>,
Michal Hocko <mhocko@suse.com>,
Thomas Garnier <thgarnie@google.com>,
Oleksiy Avramchenko <oleksiy.avramchenko@sonymobile.com>,
Steven Rostedt <rostedt@goodmis.org>,
Joel Fernandes <joelaf@google.com>,
Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@elte.hu>,
Tejun Heo <tj@kernel.org>,
"Uladzislau Rezki (Sony)" <urezki@gmail.com>
Subject: [RFC PATCH 2/2] mm: add priority threshold to __purge_vmap_area_lazy()
Date: Fri, 19 Oct 2018 19:35:38 +0200 [thread overview]
Message-ID: <20181019173538.590-3-urezki@gmail.com> (raw)
In-Reply-To: <20181019173538.590-1-urezki@gmail.com>
commit 763b218ddfaf ("mm: add preempt points into
__purge_vmap_area_lazy()")
introduced some preempt points, one of those is making
an allocation more prioritized.
Prioritizing an allocation over freeing does not work
well all the time, i.e. it should be rather a compromise.
1) Number of lazy pages directly influence on busy list
length thus on operations like: allocation, lookup, unmap,
remove, etc.
2) Under heavy simultaneous allocations/releases there may
be a situation when memory usage grows too fast hitting
out_of_memory -> panic.
Establish a threshold passing which the freeing path is
prioritized over allocation creating a balance between both.
Signed-off-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
---
mm/vmalloc.c | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index a7f257540a05..bbafcff6632b 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -1124,23 +1124,23 @@ static bool __purge_vmap_area_lazy(unsigned long start, unsigned long end)
struct llist_node *valist;
struct vmap_area *va;
struct vmap_area *n_va;
- bool do_free = false;
+ int resched_threshold;
lockdep_assert_held(&vmap_purge_lock);
valist = llist_del_all(&vmap_purge_list);
+ if (unlikely(valist == NULL))
+ return false;
+
llist_for_each_entry(va, valist, purge_list) {
if (va->va_start < start)
start = va->va_start;
if (va->va_end > end)
end = va->va_end;
- do_free = true;
}
- if (!do_free)
- return false;
-
flush_tlb_kernel_range(start, end);
+ resched_threshold = (int) lazy_max_pages() << 1;
spin_lock(&vmap_area_lock);
llist_for_each_entry_safe(va, n_va, valist, purge_list) {
@@ -1148,7 +1148,9 @@ static bool __purge_vmap_area_lazy(unsigned long start, unsigned long end)
__free_vmap_area(va);
atomic_sub(nr, &vmap_lazy_nr);
- cond_resched_lock(&vmap_area_lock);
+
+ if (atomic_read(&vmap_lazy_nr) < resched_threshold)
+ cond_resched_lock(&vmap_area_lock);
}
spin_unlock(&vmap_area_lock);
return true;
--
2.11.0
next prev parent reply other threads:[~2018-10-19 17:35 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-19 17:35 [RFC PATCH 0/2] improve vmalloc allocation Uladzislau Rezki (Sony)
2018-10-19 17:35 ` [RFC PATCH 1/2] mm/vmalloc: keep track of free blocks for allocation Uladzislau Rezki (Sony)
2018-10-29 13:39 ` [mm/vmalloc] 8dab1f5c1e: BUG:soft_lockup-CPU##stuck_for#s kernel test robot
2018-10-29 13:39 ` [LKP] " kernel test robot
2018-10-29 13:39 ` kernel test robot
2018-10-19 17:35 ` Uladzislau Rezki (Sony) [this message]
2018-10-19 22:44 ` [RFC PATCH 0/2] improve vmalloc allocation Roman Gushchin
2018-10-22 14:01 ` Uladzislau Rezki
2018-10-20 0:11 ` Joel Fernandes
2018-10-22 14:50 ` Uladzislau Rezki
2018-10-23 6:36 ` Joel Fernandes
2018-10-22 12:51 ` Michal Hocko
2018-10-22 16:52 ` Uladzislau Rezki
2018-10-23 7:23 ` Michal Hocko
2018-10-23 15:02 ` Shuah Khan
2018-10-23 15:26 ` Matthew Wilcox
2018-10-23 17:05 ` Michal Hocko
2018-10-23 17:13 ` Shuah Khan
2018-10-23 19:30 ` Joel Fernandes
2018-10-23 19:48 ` Shuah Khan
2018-10-23 20:09 ` Matthew Wilcox
2018-10-23 20:50 ` Shuah Khan
2018-10-23 21:01 ` Joel Fernandes
2018-10-24 6:22 ` Michal Hocko
2018-10-24 17:34 ` Uladzislau Rezki
2018-10-25 8:43 ` Michal Hocko
2018-10-25 10:42 ` Uladzislau Rezki
2018-10-24 16:36 ` Uladzislau Rezki
2018-10-24 23:01 ` Andrew Morton
2018-10-25 10:33 ` Uladzislau Rezki
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=20181019173538.590-3-urezki@gmail.com \
--to=urezki@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=joelaf@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=mingo@elte.hu \
--cc=oleksiy.avramchenko@sonymobile.com \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=thgarnie@google.com \
--cc=tj@kernel.org \
--cc=willy@infradead.org \
/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.