public inbox for lvm2-cvs@sourceware.org help / color / mirror / Atom feed
From: mbroz@sourceware.org To: lvm-devel@redhat.com, lvm2-cvs@sourceware.org Subject: LVM2 ./WHATS_NEW lib/metadata/metadata.c lib/m ... Date: Wed, 31 Mar 2010 17:21:00 -0000 [thread overview] Message-ID: <20100331172142.32757.qmail@sourceware.org> (raw) CVSROOT: /cvs/lvm2 Module name: LVM2 Changes by: mbroz@sourceware.org 2010-03-31 17:21:41 Modified files: . : WHATS_NEW lib/metadata : metadata.c metadata.h pv_manip.c Log message: Optimise PV segments search. The function find_peg_by_pe is incredibly inefficient for Pvs with many segments. In shiny future there should be binary (or interval) tree instead of sorted linked list (volunteers?). Anyway, for now, we can use dirty trick here to optimise this case: - Allocations are usually applied from the beginning of PV (we have no alloocation policy which allocates areas "backwards") - The only user of find_peg_by_pe is pv_split_segment() call. In *most* cases it need to split *last* PV segment. So if we search sorted pv segment list backwards, we hit the requested segment immediatelly. This patch applies this tiny change. (and saves >30% of processing time when >3000LVs segments are on one PV!) To discourage using this inefficient function from other code, it is moved to pv_manip.c and used static for now:-) Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/LVM2/WHATS_NEW.diff?cvsroot=lvm2&r1=1.1494&r2=1.1495 http://sourceware.org/cgi-bin/cvsweb.cgi/LVM2/lib/metadata/metadata.c.diff?cvsroot=lvm2&r1=1.325&r2=1.326 http://sourceware.org/cgi-bin/cvsweb.cgi/LVM2/lib/metadata/metadata.h.diff?cvsroot=lvm2&r1=1.200&r2=1.201 http://sourceware.org/cgi-bin/cvsweb.cgi/LVM2/lib/metadata/pv_manip.c.diff?cvsroot=lvm2&r1=1.22&r2=1.23 --- LVM2/WHATS_NEW 2010/03/31 17:20:44 1.1494 +++ LVM2/WHATS_NEW 2010/03/31 17:21:40 1.1495 @@ -1,5 +1,6 @@ Version 2.02.63 - ================================ + Optimise PV segments search for the most last segment search case. Remove vg_validate call when parsing cached metadata. Use hash table of LVs to speed up parsing of text metadata with many LVs. Fix two messages, add a whitespace and parentheses --- LVM2/lib/metadata/metadata.c 2010/03/31 12:06:30 1.325 +++ LVM2/lib/metadata/metadata.c 2010/03/31 17:21:40 1.326 @@ -1799,18 +1799,6 @@ return NULL; } -/* Find segment at a given physical extent in a PV */ -struct pv_segment *find_peg_by_pe(const struct physical_volume *pv, uint32_t pe) -{ - struct pv_segment *peg; - - dm_list_iterate_items(peg, &pv->segments) - if (pe >= peg->pe && pe < peg->pe + peg->len) - return peg; - - return NULL; -} - int vg_remove_mdas(struct volume_group *vg) { struct metadata_area *mda; --- LVM2/lib/metadata/metadata.h 2010/02/14 03:21:06 1.200 +++ LVM2/lib/metadata/metadata.h 2010/03/31 17:21:40 1.201 @@ -308,9 +308,6 @@ /* Find LV segment containing given LE */ struct lv_segment *find_seg_by_le(const struct logical_volume *lv, uint32_t le); -/* Find PV segment containing given LE */ -struct pv_segment *find_peg_by_pe(const struct physical_volume *pv, uint32_t pe); - /* * Remove a dev_dir if present. */ --- LVM2/lib/metadata/pv_manip.c 2008/11/03 22:14:29 1.22 +++ LVM2/lib/metadata/pv_manip.c 2010/03/31 17:21:40 1.23 @@ -78,6 +78,20 @@ return 1; } +/* Find segment at a given physical extent in a PV */ +static struct pv_segment *find_peg_by_pe(const struct physical_volume *pv, + uint32_t pe) +{ + struct pv_segment *pvseg; + + /* search backwards to optimise mostly used last segment split */ + dm_list_iterate_back_items(pvseg, &pv->segments) + if (pe >= pvseg->pe && pe < pvseg->pe + pvseg->len) + return pvseg; + + return NULL; +} + /* * Split peg at given extent. * Second part is always deallocated.
next reply other threads:[~2010-03-31 17:21 UTC|newest] Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top 2010-03-31 17:21 mbroz [this message] -- strict thread matches above, loose matches on Subject: below -- 2011-11-04 22:49 zkabelac 2011-08-10 20:17 zkabelac 2010-09-23 12:02 prajnoha 2010-07-07 2:53 agk 2009-03-16 14:35 mbroz 2008-06-23 19:04 wysochanski 2008-04-22 12:54 agk 2007-07-12 15:38 wysochanski 2007-07-12 5:04 wysochanski 2007-07-11 23:33 wysochanski 2007-06-06 19:40 wysochanski 2007-04-25 20:03 wysochanski 2007-02-07 13:29 agk 2005-04-18 14:56 agk 2004-06-19 19:27 agk
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=20100331172142.32757.qmail@sourceware.org \ --to=mbroz@sourceware.org \ --cc=lvm-devel@redhat.com \ --cc=lvm2-cvs@sourceware.org \ /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: linkBe 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 read-only IMAP folder(s) and NNTP newsgroup(s).