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.


             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: link
Be 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).