From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751505AbdARHsv (ORCPT ); Wed, 18 Jan 2017 02:48:51 -0500 Received: from LGEAMRELO12.lge.com ([156.147.23.52]:36112 "EHLO lgeamrelo12.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751226AbdARHst (ORCPT ); Wed, 18 Jan 2017 02:48:49 -0500 X-Original-SENDERIP: 156.147.1.127 X-Original-MAILFROM: iamjoonsoo.kim@lge.com X-Original-SENDERIP: 10.177.222.138 X-Original-MAILFROM: iamjoonsoo.kim@lge.com Date: Wed, 18 Jan 2017 16:54:48 +0900 From: Joonsoo Kim To: Tejun Heo Cc: vdavydov.dev@gmail.com, cl@linux.com, penberg@kernel.org, rientjes@google.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: [PATCHSET v2] slab: make memcg slab destruction scalable Message-ID: <20170118075448.GA1255@js1304-P5Q-DELUXE> References: <20170114184834.8658-1-tj@kernel.org> <20170117001256.GB25218@js1304-P5Q-DELUXE> <20170117164913.GB28948@mtj.duckdns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170117164913.GB28948@mtj.duckdns.org> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 17, 2017 at 08:49:13AM -0800, Tejun Heo wrote: > Hello, > > On Tue, Jan 17, 2017 at 09:12:57AM +0900, Joonsoo Kim wrote: > > Could you confirm that your series solves the problem that is reported > > by Doug? It would be great if the result is mentioned to the patch > > description. > > > > https://bugzilla.kernel.org/show_bug.cgi?id=172991 > > So, that's an issue in the creation path which is already resolved by > switching to an ordered workqueue (it'd probably be better to use > per-cpu wq w/ @max_active == 1 tho). This patchset is about relesae > path. slab_mutex contention would definitely go down with this but > I don't think there's more connection to it than that. That problem is caused by slow release path and then contention on the slab_mutex. With an ordered workqueue, kworker would not be created a lot but it can be possible that a lot of work items to create a new cache for memcg is pending for a long time due to slow release path. Your patchset replaces optimization for release path so it's better to check that the work isn't pending for a long time in above workload. Thanks.