From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751822AbdA2Q2g (ORCPT ); Sun, 29 Jan 2017 11:28:36 -0500 Received: from fallback2.mail.ru ([94.100.179.22]:55674 "EHLO fallback2.mail.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751699AbdA2Q15 (ORCPT ); Sun, 29 Jan 2017 11:27:57 -0500 Date: Sun, 29 Jan 2017 19:04:17 +0300 From: Vladimir Davydov To: Tejun Heo Cc: cl@linux.com, penberg@kernel.org, rientjes@google.com, iamjoonsoo.kim@lge.com, akpm@linux-foundation.org, jsvana@fb.com, hannes@cmpxchg.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, cgroups@vger.kernel.org, kernel-team@fb.com Subject: Re: [PATCH 10/10] slab: use memcg_kmem_cache_wq for slab destruction operations Message-ID: <20170129160416.GA1795@esperanza> References: <20170117235411.9408-1-tj@kernel.org> <20170117235411.9408-11-tj@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170117235411.9408-11-tj@kernel.org> Authentication-Results: smtp46.i.mail.ru; auth=pass smtp.auth=vdavydov@tarantool.org smtp.mailfrom=vdavydov@tarantool.org X-E1FCDC63: 85DCF96B421CBDA1FC213A99008719272D5CFE12AD13DA04 X-E1FCDC64: E857D01801B6CE37BF1624B86DA7C4703EA70AB56FAB2E39944FC2E2A507ACD0 X-Mailru-Sender: AA5F055C295B4E993DB4EEB14EFDCEFBA0D64CCD94A93A90D3638473EEB832D1596FF1A3A2F7952DFEDCCBD3DDE7F493 X-Mras: OK Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 17, 2017 at 03:54:11PM -0800, Tejun Heo wrote: > If there's contention on slab_mutex, queueing the per-cache > destruction work item on the system_wq can unnecessarily create and > tie up a lot of kworkers. > > Rename memcg_kmem_cache_create_wq to memcg_kmem_cache_wq and make it > global and use that workqueue for the destruction work items too. > While at it, convert the workqueue from an unbound workqueue to a > per-cpu one with concurrency limited to 1. It's generally preferable > to use per-cpu workqueues and concurrency limit of 1 is safe enough. > > This is suggested by Joonsoo Kim. > > Signed-off-by: Tejun Heo > Reported-by: Jay Vana > Cc: Vladimir Davydov > Cc: Christoph Lameter > Cc: Pekka Enberg > Cc: David Rientjes > Cc: Joonsoo Kim > Cc: Andrew Morton Acked-by: Vladimir Davydov