From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759298AbcBTTvm (ORCPT ); Sat, 20 Feb 2016 14:51:42 -0500 Received: from mx1.redhat.com ([209.132.183.28]:51309 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751946AbcBTTvi (ORCPT ); Sat, 20 Feb 2016 14:51:38 -0500 Date: Sat, 20 Feb 2016 14:51:36 -0500 From: Mike Snitzer To: Pavel Machek Cc: kernel list , axboe@fb.com, hch@lst.de Subject: Re: 4.4-final: 28 bioset threads on small notebook Message-ID: <20160220195136.GA27149@redhat.com> References: <20151211104937.GA23165@amd> <20151211140841.GA22873@redhat.com> <20160220174035.GA16459@amd> <20160220184258.GA3753@amd> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160220184258.GA3753@amd> 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 Sat, Feb 20 2016 at 1:42pm -0500, Pavel Machek wrote: > On Sat 2016-02-20 18:40:35, Pavel Machek wrote: > > > > On Fri 2015-12-11 09:08:41, Mike Snitzer wrote: > > > On Fri, Dec 11 2015 at 5:49am -0500, > > > Pavel Machek wrote: > > > > > > > Hi! > > > > > > > > I know it is normal to spawn 8 threads for every single function, > > > ... > > > > but 28 threads? > > > > > > > > root 974 0.0 0.0 0 0 ? S< Dec08 0:00 [bioset] > > > ... > > > > > > How many physical block devices do you have? > > > > > > DM is doing its part to not contribute to this: > > > dbba42d8a ("dm: eliminate unused "bioset" process for each bio-based DM device") > > > > > > (but yeah, all these extra 'bioset' threads aren't ideal) > > > > Still there in 4.4-final. > > ...and still there in 4.5-rc4 :-(. > Pavel You're directing this concern to the wrong person. I already told you DM is _not_ contributing any extra "bioset" threads (ever since commit dbba42d8a). But in general, these "bioset" threads are a side-effect of the late-bio-splitting support. So is your position on it: "I don't like that feature if it comes at the expense of adding resources I can _see_ for something I (naively?) view as useless"? Just seems... naive... but you could be trying to say something else entirely. Anyway, if you don't like something: understand why it is there and then try to fix it to your liking (without compromising why it was there to begin with).