Re: Improve processing efficiency for addition and deletion of multipath devices

[Martin Wilck <mwilck@suse.com>]

On Tue, 2016-11-29 at 07:47 +0100, Hannes Reinecke wrote:
> On 11/28/2016 07:46 PM, Benjamin Marzinski wrote:
> > On Thu, Nov 24, 2016 at 10:21:10AM +0100, Martin Wilck wrote:
> > > On Fri, 2016-11-18 at 16:26 -0600, Benjamin Marzinski wrote:
> > > 
> > > > At any rate, I'd rather get rid of the gazillion waiter threads
> > > > first.
> > > 
> > > Hm, I thought the threads are good because this avoids one
> > > unresponsive
> > > device to stall everything?
> > 
> > There is work making dm events pollable, so that you can wait for
> > any
> > number of them with one thread. At the moment, once we get an
> > event, we
> > lock the vecs lock, which pretty much keeps everything else from
> > running, so this doesn't really change that.
> > 
> 
> Which again leads me to the question:
> Why are we waiting for dm events?
> The code handling them is pretty arcane, and from what I've seen
> there
> is nothing in there which we wouldn't be informed via other
> mechanisms
> (path checker, uevents).
> So why do we still bother with them?

I was asking myself the same question. From my inspection of the kernel
code, there are two code paths that trigger a dm event but no uevent
(bypass_pg() and switch_pg_num(), both related to path group
switching). If these are covered by the path checker, I see no point in
waiting for DM events. But of course, I may be missing something.

Regards,
Martin


-- 
Dr. Martin Wilck <mwilck@suse.com>, Tel. +49 (0)911 74053 2107
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)

--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel