All of lore.kernel.org
 help / color / mirror / Atom feed
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



             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.