From: Pavel Machek <pavel@ucw.cz>
To: Mike Snitzer <snitzer@redhat.com>
Cc: kernel list <linux-kernel@vger.kernel.org>,
axboe@fb.com, hch@lst.de, kent.overstreet@gmail.com,
neilb@suse.de, martin.petersen@oracle.com, dpark@posteo.net,
ming.l@ssi.samsung.com, dm-devel@redhat.com,
ming.lei@canonical.com, agk@redhat.com, jkosina@suse.cz,
geoff@infradead.org, jim@jtan.com, pjk1939@linux.vnet.ibm.com,
minchan@kernel.org, ngupta@vflare.org, oleg.drokin@intel.com,
andreas.dilger@intel.com
Subject: Re: 4.4-final: 28 bioset threads on small notebook
Date: Sat, 20 Feb 2016 21:04:32 +0100 [thread overview]
Message-ID: <20160220200432.GB22120@amd> (raw)
In-Reply-To: <20160220195136.GA27149@redhat.com>
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 :-(.
>
> 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).
Well, sorry about that. Note that l-k is on the cc list, so hopefully
the right person sees it too.
Ok, let me check... it seems that
54efd50bfd873e2dbf784e0b21a8027ba4299a3e is responsible, thus Kent
Overstreet <kent.overstreet@gmail.com> is to blame.
Um, and you acked the patch, so you are partly responsible.
> 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).
Well, 28 kernel threads on a notebook is a bug, plain and simple. Do
you argue it is not?
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
next prev parent reply other threads:[~2016-02-20 20:04 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-12-11 10:49 4.4-rc: 28 bioset threads on small notebook Pavel Machek
2015-12-11 14:08 ` Mike Snitzer
2015-12-11 17:14 ` Pavel Machek
2016-02-20 17:40 ` 4.4-final: " Pavel Machek
2016-02-20 18:42 ` Pavel Machek
2016-02-20 19:51 ` Mike Snitzer
2016-02-20 20:04 ` Pavel Machek [this message]
2016-02-20 20:38 ` Mike Snitzer
2016-02-20 20:55 ` Pavel Machek
2016-02-21 4:15 ` Kent Overstreet
2016-02-21 6:43 ` Ming Lin-SSI
2016-02-21 9:40 ` Ming Lei
2016-02-22 22:58 ` Kent Overstreet
2016-02-23 2:55 ` Ming Lei
2016-02-23 14:54 ` Mike Snitzer
2016-02-24 2:48 ` Ming Lei
2016-02-24 3:23 ` Kent Overstreet
2016-02-23 20:45 ` Pavel Machek
2017-02-06 12:53 ` v4.9, 4.4-final: 28 bioset threads on small notebook, 36 threads on cellphone Pavel Machek
2017-02-07 1:47 ` Kent Overstreet
2017-02-07 2:49 ` Kent Overstreet
2017-02-07 17:13 ` Mike Snitzer
2017-02-07 20:39 ` Pavel Machek
2017-02-08 3:12 ` Mike Galbraith
2017-02-08 4:58 ` Kent Overstreet
2017-02-08 6:22 ` [PATCH] block: Make rescuer threads per request_queue, not per bioset kbuild test robot
2017-02-08 6:23 ` kbuild test robot
2017-02-08 6:57 ` v4.9, 4.4-final: 28 bioset threads on small notebook, 36 threads on cellphone Mike Galbraith
2017-02-08 16:34 ` Mike Snitzer
2017-02-09 21:25 ` Kent Overstreet
2017-02-14 16:34 ` [dm-devel] " Mikulas Patocka
2017-02-14 17:33 ` Mike Snitzer
2017-02-08 2:47 ` Ming Lei
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160220200432.GB22120@amd \
--to=pavel@ucw.cz \
--cc=agk@redhat.com \
--cc=andreas.dilger@intel.com \
--cc=axboe@fb.com \
--cc=dm-devel@redhat.com \
--cc=dpark@posteo.net \
--cc=geoff@infradead.org \
--cc=hch@lst.de \
--cc=jim@jtan.com \
--cc=jkosina@suse.cz \
--cc=kent.overstreet@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=minchan@kernel.org \
--cc=ming.l@ssi.samsung.com \
--cc=ming.lei@canonical.com \
--cc=neilb@suse.de \
--cc=ngupta@vflare.org \
--cc=oleg.drokin@intel.com \
--cc=pjk1939@linux.vnet.ibm.com \
--cc=snitzer@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).