public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Nadia Derbey <Nadia.Derbey@bull.net>
To: Tim Pepper <lnxninja@linux.vnet.ibm.com>
Cc: manfred@colorfullife.com, paulmck@linux.vnet.ibm.com,
	linux-kernel@vger.kernel.org, efault@gmx.de,
	akpm@linux-foundation.org
Subject: Re: [PATCH 05/10] Introduce ridr_get_new_above()
Date: Mon, 05 May 2008 12:33:09 +0200	[thread overview]
Message-ID: <481EE265.1020405@bull.net> (raw)
In-Reply-To: <20080501043204.GD30274@tpepper-t42p.dolavim.us>

Tim Pepper wrote:
> On Tue 29 Apr at 16:33:09 +0200 Nadia.Derbey@bull.net said:
> 
>>[PATCH 05/10]
>>
>>This patch introduces the ridr_get_new_above() routine, and some common code
>>between the idr an ridr API's.
> 
> 
> The ridr_get_new_above() is the first place we see something really
> different compared to idr (an RCU addition).  This is a lot of patching
> so far for what would be a small incremental change otherwise.
> 
> 
>>Index: linux-2.6.25-mm1/include/linux/idr.h
>>===================================================================
>>--- linux-2.6.25-mm1.orig/include/linux/idr.h	2008-04-29 13:08:00.000000000 +0200
>>+++ linux-2.6.25-mm1/include/linux/idr.h	2008-04-29 14:08:47.000000000 +0200
>>@@ -71,6 +71,27 @@ struct idr {
>> }
>> #define DEFINE_IDR(name)	struct idr name = IDR_INIT(name)
>>
>>+/* Actions to be taken after a call to _idr_sub_alloc */
>>+#define IDR_DONE         -1
>>+#define IDR_NEED_TO_GROW -2
>>+#define IDR_NOMORE_SPACE -3
>>+#define IDR_GO_TOP       -4
>>+#define IDR_GO_UP        -5
> 
> 
> This stuff is useful on its own in as much as it improves code
> readability.  A lot of this patch (the "some common code between the
> idr and ridr API's" part) could be a standalone patch distinct from the
> ridr series and then be at the head of your stack.
> 
> 
>>+			return action;
>>+		case IDR_DONE:
>>+			goto end_loop;
>>+		case IDR_GO_UP:
>>+			continue;
>>+		case IDR_GO_TOP:
>>+			goto restart;
>>+		default:
>>+			m = action;
>> 			break;
>>+		}
>>+		BUG_ON(m < 0);
> 
> 
> Why the added BUG_ON()?  These couple hunks are a bit muddled, so maybe I
> missed something.  But I don't see anything different in how m or bm are
> being manipulated such that m<0 is anymore likely after this patch.
> 
> 
>>Index: linux-2.6.25-mm1/lib/ridr.c
>>===================================================================
>>--- linux-2.6.25-mm1.orig/lib/ridr.c	2008-04-29 13:23:17.000000000 +0200
>>+++ linux-2.6.25-mm1/lib/ridr.c	2008-04-29 14:03:35.000000000 +0200
>>@@ -11,6 +11,23 @@
>> static struct kmem_cache *ridr_layer_cache;
>>
>>
>>+static struct ridr_layer *get_from_free_list(struct ridr *idp)
>>+{
>>+	struct ridr_layer *q;
>>+	struct idr_layer *p;
>>+	unsigned long flags;
>>+
>>+	spin_lock_irqsave(&idp->lock, flags);
>>+	if ((q = idp->id_free)) {
>>+		p = ridr_to_idr(q);
>>+		idp->id_free = p->ary[0];
>>+		idp->id_free_cnt--;
>>+		p->ary[0] = NULL;
>>+	}
>>+	spin_unlock_irqrestore(&idp->lock, flags);
>>+	return(q);
>>+}
>>+
> 
> 
> idr's alloc_layer() in disguise?
> 
> 
>>+static int sub_alloc(struct ridr *idp, int *starting_id,
>>+			struct ridr_layer **rpa, struct idr_layer **pa)
> 
> 
> ...
> More or less duplication
> ...
> 
> 
>>+		 * Create the layer below if it is missing.
>>+		 */
>>+		if (!p->ary[m]) {
>>+			new = get_from_free_list(idp);
>>+			if (!new)
>>+				return -1;
>>+			rcu_assign_pointer(p->ary[m], new);
>>+			p->count++;
>>+		}
>>+		pa[l] = p;
>>+		rpa[l--] = idr_to_ridr(p);
>>+		p = p->ary[m];
>>+	}
>>+
>>+end_loop:
>>+	pa[l] = p;
>>+	rpa[l] = idr_to_ridr(p);
>>+	return id;
>>+}
> 
> 
> Oh but wait..there's some RCU-ness tucked in there.
> 
> 
>>+
>>+static int ridr_get_empty_slot(struct ridr *idp, int starting_id,
>>+			      struct ridr_layer **rpa, struct idr_layer **pa)
>>+{
>>+	struct ridr_layer *p, *rnew;
>>+	int layers, v, id;
>>+	unsigned long flags;
>>+
>>+	id = starting_id;
>>+build_up:
>>+	p = idp->top;
>>+	layers = idp->layers;
>>+	if (unlikely(!p)) {
>>+		p = get_from_free_list(idp);
>>+		if (!p)
>>+			return -1;
>>+		layers = 1;
>>+	}
>>+	/*
>>+	 * Add a new layer to the top of the tree if the requested
>>+	 * id is larger than the currently allocated space.
>>+	 */
>>+	while (layers < MAX_LEVEL - 1 && id >= (1 << (layers * IDR_BITS))) {
> 
>                ^^                   ^^
> Dropped some parens.  Otherwise more duplication...
> 
> 
>>+				rnew->idr.ary[0] = NULL;
>>+				rnew->idr.bitmap = rnew->idr.count = 0;
>>+				__move_to_free_list(idp, rnew);
>>+			}
>>+			spin_unlock_irqrestore(&idp->lock, flags);
>>+			return -1;
>>+		}
>>+		_idr_set_new_slot(ridr_to_idr(rnew), ridr_to_idr(p));
>>+		p = rnew;
>>+	}
>>+	rcu_assign_pointer(idp->top, p);
>>+	idp->layers = layers;
>>+	v = sub_alloc(idp, &id, rpa, pa);
>>+	if (v == IDR_NEED_TO_GROW)
>>+		goto build_up;
>>+	return(v);
>>+}
> 
> 
> Some more RCU.
> 
> 
>>+static int ridr_get_new_above_int(struct ridr *idp, void *ptr, int starting_id)
>>+{
>>+	struct ridr_layer *rpa[MAX_LEVEL];
>>+	struct idr_layer *pa[MAX_LEVEL];
>>+	int id;
>>+
>>+	id = ridr_get_empty_slot(idp, starting_id, rpa, pa);
>>+	if (id >= 0) {
>>+		/*
>>+		 * Successfully found an empty slot.  Install the user
>>+		 * pointer and mark the slot full.
>>+		 */
>>+		rcu_assign_pointer(pa[0]->ary[id & IDR_MASK],
>>+				(struct ridr_layer *)ptr);
>>+		pa[0]->count++;
>>+		_idr_mark_full(pa, id);
>>+	}
>>+
>>+	return id;
>>+}
> 
> 
> And other line of RCU.
> 
> OK.  So at this point in patch 5/10 we've got 3 lines of new code and
> hundreds of lines of duplicated code?
> 
> A while more looking through the rest of the patches for the rest of the
> context and I might be able to actually think about the implications of
> these three lines being where they are.
> 
> Locking changes are complicated enough without all this obfuscation!
> I understand the desire to not break IDR, but...
> 

OK, you convinced me. I'll re-send a new patchset that is incremental on 
top of idr. Sorry (and thanks a lot) for the painful review!

Regards,
Nadia

  reply	other threads:[~2008-05-05 10:33 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-29 14:33 [PATCH 00/10] Scalability requirements for sysv ipc - v2 Nadia.Derbey
2008-04-29 14:33 ` [PATCH 01/10] Fix idr_remove() Nadia.Derbey
2008-04-29 18:44   ` Andrew Morton
2008-05-05  9:26     ` Nadia Derbey
2008-04-29 14:33 ` [PATCH 02/10] Introduce the ridr structure Nadia.Derbey
2008-05-01  4:30   ` Tim Pepper
2008-04-29 14:33 ` [PATCH 03/10] Introduce ridr_pre_get() Nadia.Derbey
2008-05-01  4:31   ` Tim Pepper
2008-04-29 14:33 ` [PATCH 04/10] Introduce ridr_init() Nadia.Derbey
2008-05-01  4:31   ` Tim Pepper
2008-04-29 14:33 ` [PATCH 05/10] Introduce ridr_get_new_above() Nadia.Derbey
2008-05-01  4:32   ` Tim Pepper
2008-05-05 10:33     ` Nadia Derbey [this message]
2008-04-29 14:33 ` [PATCH 06/10] Introduce ridr_get_new() Nadia.Derbey
2008-05-01  4:32   ` Tim Pepper
2008-04-29 14:33 ` [PATCH 07/10] Introduce ridr_find() Nadia.Derbey
2008-05-01  4:32   ` Tim Pepper
2008-04-29 14:33 ` [PATCH 08/10] Introduce ridr_remove() Nadia.Derbey
2008-05-01  4:32   ` Tim Pepper
2008-04-29 14:33 ` [PATCH 09/10] Integrate the ridr code into IPC code Nadia.Derbey
2008-05-01  4:32   ` Tim Pepper
2008-04-29 14:33 ` [PATCH 10/10] Get rid of ipc_lock_down() Nadia.Derbey
2008-05-01  4:33   ` Tim Pepper
2008-04-29 18:54 ` [PATCH 00/10] Scalability requirements for sysv ipc - v2 Andrew Morton
2008-05-05 16:52   ` Nadia Derbey
2008-05-05 17:07     ` Andrew Morton

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=481EE265.1020405@bull.net \
    --to=nadia.derbey@bull.net \
    --cc=akpm@linux-foundation.org \
    --cc=efault@gmx.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lnxninja@linux.vnet.ibm.com \
    --cc=manfred@colorfullife.com \
    --cc=paulmck@linux.vnet.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox