From: Zdenek Kabelac <zkabelac@redhat.com>
To: lvm-devel@redhat.com
Subject: [PATCH 0/9] Udev latency
Date: Wed, 8 Dec 2010 13:57:46 +0100 [thread overview]
Message-ID: <cover.1291802397.git.zkabelac@redhat.com> (raw)
WARNING - Not a final patch - this is patch for discussion WARNING
Patch addresses udev latencies we may observe with commands
like 'vgchange -ay' when the command waits after dm table is created
also for udev to process its rules for each every created device.
This adds uncessary delays for larger LV sets.
Here are some basic numbers -
First number is taken on clean tree and (the second) is my own modified
code that has few more accelerations i.e. memlock & config parsing mods
which are however not yet in generably 'usable' form.
During tests - gvfs/gdu/udisk daemons were killed.
My testing vg contains 1708 linear devices.
vgchange -ay
Without udev in use (with current todays rawhide udev-164-6 package
which is in fact noticable slower) - 1:30.6 (55.2sec)
When latency patch is in use - 1:29 (44.8sec) (10sec diff - ~23%)
vgchange -an
Without udev latency patch - 2:35 (1:33.7)
With udev latency patch - 2:34 (1:31.4) (so only 2sec difference! ~3%)
NOTE:
Tests've been repeated several times - times are relatively stable.
Another interesting note - before today's udev upgrade - it's been 30%/5%.
With older udev - thing were faster, and differences were bigger.
TODO:
Release memlock & config parser patches - as they give big improvements.
Though I want to discusse them first a bit - as the proper solution could
be a bit tricky.
Zdenek Kabelac (9):
Add get_lib_cookie
Move fs_unlock
Add lvm_do_unlock_fs
Use internal cookie for dm_tree functions
Stop calling fs_unlock() and dm_udev_wait()
Add LCK_UNLOCK_FS and unlock_fs
Add CLVMD_CMD_UNLOCK_FS command
Locking with unlock_fs
Wait for devices being created
daemons/clvmd/clvm.h | 1 +
daemons/clvmd/clvmd-command.c | 6 ++
daemons/clvmd/clvmd.c | 3 +
daemons/clvmd/lvm-functions.c | 7 +++
daemons/clvmd/lvm-functions.h | 1 +
lib/activate/activate.c | 5 ++
lib/activate/activate.h | 2 +
lib/activate/dev_manager.c | 17 +------
lib/activate/fs.c | 1 +
lib/activate/fs.h | 1 -
lib/locking/cluster_locking.c | 7 +++
lib/locking/file_locking.c | 6 ++
lib/locking/locking.h | 4 ++
lib/metadata/lv_manip.c | 3 +
libdm/libdm-common.c | 23 +++++++++
libdm/libdm-common.h | 1 +
libdm/libdm-deptree.c | 106 +++++++++++++++++++++++++++++++++++-----
tools/lvmcmdline.c | 3 +
18 files changed, 166 insertions(+), 31 deletions(-)
--
1.7.3.3
next reply other threads:[~2010-12-08 12:57 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-08 12:57 Zdenek Kabelac [this message]
2010-12-08 12:57 ` [PATCH 1/9] Add get_lib_cookie Zdenek Kabelac
2010-12-08 12:57 ` [PATCH 2/9] Move fs_unlock Zdenek Kabelac
2010-12-08 12:57 ` [PATCH 3/9] Add lvm_do_unlock_fs Zdenek Kabelac
2010-12-08 12:57 ` [PATCH 4/9] Use internal cookie for dm_tree functions Zdenek Kabelac
2010-12-08 12:57 ` [PATCH 5/9] Stop calling fs_unlock() and dm_udev_wait() Zdenek Kabelac
2010-12-08 12:57 ` [PATCH 6/9] Add LCK_UNLOCK_FS and unlock_fs Zdenek Kabelac
2010-12-08 12:57 ` [PATCH 7/9] Add CLVMD_CMD_UNLOCK_FS command Zdenek Kabelac
2010-12-08 12:57 ` [PATCH 8/9] Locking with unlock_fs Zdenek Kabelac
2010-12-08 12:57 ` [PATCH 9/9] Wait for devices being created Zdenek Kabelac
2010-12-10 17:00 ` [PATCH 0/9] Udev latency Alasdair G Kergon
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=cover.1291802397.git.zkabelac@redhat.com \
--to=zkabelac@redhat.com \
--cc=lvm-devel@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.