Dne 29.11.2016 v 09:02 Martin Wilck napsal(a):
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.
Processing of 'dm' events likely should be postponed to 'dmeventd' -
which is a daemon resolving the problem here with waiting for an event.
Plugin just takes the action.
IMHO there is nothing easier you can have.
It's then upto dmeventd to maintain the best 'connection' with kernel and
events.
But still - I'd really like to see the focus to target to biggest bottleneck
first - i.e. 'blkid' executed on appearing & disappearing component devices.
Regards
Zdenek
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
