From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751374AbdBDQXW (ORCPT ); Sat, 4 Feb 2017 11:23:22 -0500 Received: from terminus.zytor.com ([65.50.211.136]:56760 "EHLO terminus.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751349AbdBDQXV (ORCPT ); Sat, 4 Feb 2017 11:23:21 -0500 Date: Sat, 4 Feb 2017 08:23:07 -0800 From: tip-bot for Waiman Long Message-ID: Cc: hpa@zytor.com, jstancek@redhat.com, tglx@linutronix.de, changbin.du@intel.com, akpm@linux-foundation.org, longman@redhat.com, borntraeger@de.ibm.com, linux-kernel@vger.kernel.org, mingo@kernel.org Reply-To: changbin.du@intel.com, longman@redhat.com, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, borntraeger@de.ibm.com, mingo@kernel.org, jstancek@redhat.com, tglx@linutronix.de, hpa@zytor.com In-Reply-To: <1483647425-4135-3-git-send-email-longman@redhat.com> References: <1483647425-4135-3-git-send-email-longman@redhat.com> To: linux-tip-commits@vger.kernel.org Subject: [tip:core/debugobjects] debugobjects: Scale thresholds with # of CPUs Git-Commit-ID: 97dd552eb23c83dbf626a6e84666c7e281375d47 X-Mailer: tip-git-log-daemon Robot-ID: Robot-Unsubscribe: Contact to get blacklisted from these emails MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Commit-ID: 97dd552eb23c83dbf626a6e84666c7e281375d47 Gitweb: http://git.kernel.org/tip/97dd552eb23c83dbf626a6e84666c7e281375d47 Author: Waiman Long AuthorDate: Thu, 5 Jan 2017 15:17:04 -0500 Committer: Thomas Gleixner CommitDate: Sat, 4 Feb 2017 09:01:55 +0100 debugobjects: Scale thresholds with # of CPUs 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 Cc: Christian Borntraeger Cc: "Du Changbin" Cc: Andrew Morton Cc: Jan Stancek Link: http://lkml.kernel.org/r/1483647425-4135-3-git-send-email-longman@redhat.com Signed-off-by: Thomas Gleixner --- lib/debugobjects.c | 20 +++++++++++++++----- 1 file changed, 15 insertions(+), 5 deletions(-) diff --git a/lib/debugobjects.c b/lib/debugobjects.c index d78673e..dc78217 100644 --- a/lib/debugobjects.c +++ b/lib/debugobjects.c @@ -52,7 +52,10 @@ static int debug_objects_fixups __read_mostly; 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; /* @@ -94,13 +97,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) @@ -176,7 +179,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--; @@ -206,7 +209,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 = 1; hlist_add_head(&obj->node, &obj_pool); obj_pool_free++; @@ -1126,4 +1129,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; }