Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1534484 > unrolled thread
| Started by | Waiman Long <longman@redhat.com> |
|---|---|
| First post | 2016-12-01 23:00 +0100 |
| Last post | 2016-12-01 23:00 +0100 |
| Articles | 2 — 1 participant |
Back to article view | Back to linux.kernel
[PATCH 0/3] debugobjects: Reduce global pool_lock contention Waiman Long <longman@redhat.com> - 2016-12-01 23:00 +0100
[PATCH 1/3] debugobjects: Scale thresholds with # of CPUs Waiman Long <longman@redhat.com> - 2016-12-01 23:00 +0100
| From | Waiman Long <longman@redhat.com> |
|---|---|
| Date | 2016-12-01 23:00 +0100 |
| Subject | [PATCH 0/3] debugobjects: Reduce global pool_lock contention |
| Message-ID | <sJHyy-2B4-15@gated-at.bofh.it> |
This patchset aims to reduce contention of the global pool_lock while improving performance at the same time. It is done to resolve the following soft lockup problem with a debug kernel in some of the large SMP systems: NMI watchdog: BUG: soft lockup - CPU#35 stuck for 22s! [rcuos/1:21] ... RIP: 0010:[<ffffffff817c216b>] [<ffffffff817c216b>] _raw_spin_unlock_irqrestore+0x3b/0x60 ... Call Trace: [<ffffffff813f40d1>] free_object+0x81/0xb0 [<ffffffff813f4f33>] debug_check_no_obj_freed+0x193/0x220 [<ffffffff81101a59>] ? trace_hardirqs_on_caller+0xf9/0x1c0 [<ffffffff81284996>] ? file_free_rcu+0x36/0x60 [<ffffffff81251712>] kmem_cache_free+0xd2/0x380 [<ffffffff81284960>] ? fput+0x90/0x90 [<ffffffff81284996>] file_free_rcu+0x36/0x60 [<ffffffff81124c23>] rcu_nocb_kthread+0x1b3/0x550 [<ffffffff81124b71>] ? rcu_nocb_kthread+0x101/0x550 [<ffffffff81124a70>] ? sync_exp_work_done.constprop.63+0x50/0x50 [<ffffffff810c59d1>] kthread+0x101/0x120 [<ffffffff81101a59>] ? trace_hardirqs_on_caller+0xf9/0x1c0 [<ffffffff817c2d32>] ret_from_fork+0x22/0x50 On a 8-socket IvyBridge-EX system (120 cores, 240 threads), the elapsed time of a 4.9-rc7 kernel parallel build (make -j 240) was reduced from 7m57s to 7m19s with a patched 4.9-rc7 kernel. There was also about a 10X reduction in the number of debug objects being allocated from or freed to the kmemcache during the kernel build. Waiman Long (3): debugobjects: Scale thresholds with # of CPUs debugobjects: Track number of kmem_cache_alloc/kmem_cache_free done debugobjects: Reduce contention on the global pool_lock lib/debugobjects.c | 57 ++++++++++++++++++++++++++++++++++++++++++------------ 1 file changed, 45 insertions(+), 12 deletions(-) -- 1.8.3.1
[toc] | [next] | [standalone]
| From | Waiman Long <longman@redhat.com> |
|---|---|
| Date | 2016-12-01 23:00 +0100 |
| Subject | [PATCH 1/3] debugobjects: Scale thresholds with # of CPUs |
| Message-ID | <sJHyz-2B4-35@gated-at.bofh.it> |
| In reply to | #1534484 |
On a large SMP systems with hundreds of CPUs, the current thresholds
for allocating and freeing debug objects (256 and 1024 respectively)
may not work well. This can cause a lot of needless calls to
kmem_aloc() and kmem_free() on those systems.
To alleviate this thrashing problem, the object freeing threshold
is now increased to "1024 + # of CPUs * 32". Whereas the object
allocation threshold is increased to "256 + # of CPUs * 4". That
should make the debug objects subsystem scale better with the number
of CPUs available in the system.
Signed-off-by: Waiman Long <longman@redhat.com>
---
lib/debugobjects.c | 20 +++++++++++++++-----
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/lib/debugobjects.c b/lib/debugobjects.c
index a8e1260..bb415a7 100644
--- a/lib/debugobjects.c
+++ b/lib/debugobjects.c
@@ -52,7 +52,10 @@ struct debug_bucket {
static int debug_objects_warnings __read_mostly;
static int debug_objects_enabled __read_mostly
= CONFIG_DEBUG_OBJECTS_ENABLE_DEFAULT;
-
+static int debug_objects_pool_size __read_mostly
+ = ODEBUG_POOL_SIZE;
+static int debug_objects_pool_min_level __read_mostly
+ = ODEBUG_POOL_MIN_LEVEL;
static struct debug_obj_descr *descr_test __read_mostly;
static void free_obj_work(struct work_struct *work);
@@ -88,13 +91,13 @@ static void fill_pool(void)
struct debug_obj *new;
unsigned long flags;
- if (likely(obj_pool_free >= ODEBUG_POOL_MIN_LEVEL))
+ if (likely(obj_pool_free >= debug_objects_pool_min_level))
return;
if (unlikely(!obj_cache))
return;
- while (obj_pool_free < ODEBUG_POOL_MIN_LEVEL) {
+ while (obj_pool_free < debug_objects_pool_min_level) {
new = kmem_cache_zalloc(obj_cache, gfp);
if (!new)
@@ -169,7 +172,7 @@ static void free_obj_work(struct work_struct *work)
unsigned long flags;
raw_spin_lock_irqsave(&pool_lock, flags);
- while (obj_pool_free > ODEBUG_POOL_SIZE) {
+ while (obj_pool_free > debug_objects_pool_size) {
obj = hlist_entry(obj_pool.first, typeof(*obj), node);
hlist_del(&obj->node);
obj_pool_free--;
@@ -198,7 +201,7 @@ static void free_object(struct debug_obj *obj)
* schedule work when the pool is filled and the cache is
* initialized:
*/
- if (obj_pool_free > ODEBUG_POOL_SIZE && obj_cache)
+ if (obj_pool_free > debug_objects_pool_size && obj_cache)
sched = keventd_up();
hlist_add_head(&obj->node, &obj_pool);
obj_pool_free++;
@@ -1108,4 +1111,11 @@ void __init debug_objects_mem_init(void)
pr_warn("out of memory.\n");
} else
debug_objects_selftest();
+
+ /*
+ * Increase the thresholds for allocating and freeing objects
+ * according to the number of possible CPUs available in the system.
+ */
+ debug_objects_pool_size += num_possible_cpus() * 32;
+ debug_objects_pool_min_level += num_possible_cpus() * 4;
}
--
1.8.3.1
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web