linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton@redhat.com>
To: Tejun Heo <tj@kernel.org>
Cc: "J. Bruce Fields" <bfields@fieldses.org>,
	akpm@linux-foundation.org, linux-kernel@vger.kernel.org,
	rusty@rustcorp.com.au, skinsbursky@parallels.com,
	ebiederm@xmission.com, jmorris@namei.org, axboe@kernel.dk
Subject: Re: [PATCHSET] idr: implement idr_alloc() and convert existing users
Date: Tue, 26 Mar 2013 11:19:36 -0400	[thread overview]
Message-ID: <20130326111936.550110bf@tlielax.poochiereds.net> (raw)
In-Reply-To: <20130321183513.GC20500@htj.dyndns.org>

On Thu, 21 Mar 2013 11:35:13 -0700
Tejun Heo <tj@kernel.org> wrote:

> Hello,
> 
> On Thu, Mar 21, 2013 at 10:06:18AM -0400, J. Bruce Fields wrote:
> > > Ooh, BTW, the cyclic allocation is broken.  It's prone to -ENOSPC
> > > after the first wraparound.  There are several cyclic users in the
> > > kernel and I think it probably would be best to implement cyclic
> > > support in idr.
> > 
> > Are you looking at this, by the way, or do you have any suggestions?
> > 
> > Wondering if it's something I should try to fix or if I should look into
> > converting to some other data structure here.
> 
> I am not working on it at the moment but I think the logical thing to
> do would be implementing cyclic support in idr and enabling it with,
> say, a different initializer - IDR_CYCLIC_INIT() or something.  If you
> wanna fix it, please go ahead. :)
> 
> Thanks.
> 

So, here's a first (very rough, completely untested) pass at fixing
this for cyclic allocations. This looks like it'll probably fix the
ENOSPC errors when the counter wraps.

I'm not sure this is really what's needed though.

Suppose we have a situation where most of the currently allocated IDs
are clustered near the top of the range. When the counter wraps and we
call idr_alloc with a low start value, won't it prefer to allocate from
an existing layer instead of creating a new one?

If so, then means that after the counter wraps, it can skip over all of
the low values and reuse a more recently used high value. Is that OK
for the existing cyclic users? Or do we need to do something more
elaborate to make it prefer IDs at the low ranges after the counter
wraps?

-------------------[snip]--------------------

[PATCH] idr: introduce idr_alloc_cyclic

Thus spake Tejun Heo:

    Ooh, BTW, the cyclic allocation is broken.  It's prone to -ENOSPC
    after the first wraparound.  There are several cyclic users in the
    kernel and I think it probably would be best to implement cyclic
    support in idr.

This patch does that by adding new idr_alloc_cyclic function that
such users in the kernel can use. The idea here is that the caller will
keep a static counter of some sort that we can use to track where
the next "start" value should be on the next allocation.

Signed-off-by: Jeff Layton <jlayton@redhat.com>
---
 include/linux/idr.h |  1 +
 lib/idr.c           | 27 +++++++++++++++++++++++++++
 2 files changed, 28 insertions(+)

diff --git a/include/linux/idr.h b/include/linux/idr.h
index 2640c7e..c6ac330 100644
--- a/include/linux/idr.h
+++ b/include/linux/idr.h
@@ -75,6 +75,7 @@ struct idr {
 void *idr_find_slowpath(struct idr *idp, int id);
 void idr_preload(gfp_t gfp_mask);
 int idr_alloc(struct idr *idp, void *ptr, int start, int end, gfp_t gfp_mask);
+int idr_alloc_cyclic(struct idr *idr, void *ptr, int start, int end, int *cur, gfp_t gfp_mask);
 int idr_for_each(struct idr *idp,
 		 int (*fn)(int id, void *p, void *data), void *data);
 void *idr_get_next(struct idr *idp, int *nextid);
diff --git a/lib/idr.c b/lib/idr.c
index 322e281..d835dba 100644
--- a/lib/idr.c
+++ b/lib/idr.c
@@ -495,6 +495,33 @@ int idr_alloc(struct idr *idr, void *ptr, int start, int end, gfp_t gfp_mask)
 }
 EXPORT_SYMBOL_GPL(idr_alloc);
 
+/**
+ * idr_alloc_cyclic - allocate new idr entry in a cyclical fashion
+ * @idr: the (initialized) idr
+ * @ptr: pointer to be associated with the new id
+ * @start: the minimum id (inclusive)
+ * @end: the maximum id (exclusive, <= 0 for max)
+ * @cur: ptr to current position in the range (typically, last allocated + 1)
+ * @gfp_mask: memory allocation flags
+ *
+ * Essentially the same as idr_alloc, but prefers to allocate progressively
+ * higher ids if it can. If the "cur" counter wraps, then it will start again
+ * at the "start" end of the range and allocate one that has already been used.
+ */
+int idr_alloc_cyclic(struct idr *idr, void *ptr, int start, int end, int *cur,
+			gfp_t gfp_mask)
+{
+	int id;
+
+	id = idr_alloc(idr, ptr, *cur, end, gfp_mask);
+	if (id == -ENOSPC)
+		id = idr_alloc(idr, ptr, start, end, gfp_mask);
+
+	if (likely(id >= 0))
+		*cur = id + 1;
+	return id;
+}
+
 static void idr_remove_warning(int id)
 {
 	printk(KERN_WARNING
-- 
1.7.11.7


  reply	other threads:[~2013-03-26 15:20 UTC|newest]

Thread overview: 128+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-03  1:20 [PATCHSET] idr: implement idr_alloc() and convert existing users Tejun Heo
2013-02-03  1:20 ` [PATCH 01/62] idr: cosmetic updates to struct / initializer definitions Tejun Heo
2013-02-03  1:20 ` [PATCH 02/62] idr: relocate idr_for_each_entry() and reorganize id[r|a]_get_new() Tejun Heo
2013-02-03  1:20 ` [PATCH 03/62] idr: remove _idr_rc_to_errno() hack Tejun Heo
2013-02-03  1:20 ` [PATCH 04/62] idr: refactor idr_get_new_above() Tejun Heo
2013-02-03  1:20 ` [PATCH 05/62] idr: implement idr_preload[_end]() and idr_alloc() Tejun Heo
2013-02-04 18:32   ` [PATCH v2 " Tejun Heo
2013-02-03  1:20 ` [PATCH 06/62] block: fix synchronization and limit check in blk_alloc_devt() Tejun Heo
2013-02-06 11:00   ` Jens Axboe
2013-02-03  1:20 ` [PATCH 07/62] block: convert to idr_alloc() Tejun Heo
2013-02-04 13:10   ` Jens Axboe
2013-02-03  1:20 ` [PATCH 08/62] block/loop: " Tejun Heo
2013-02-04 13:11   ` Jens Axboe
2013-02-03  1:20 ` [PATCH 09/62] atm/nicstar: " Tejun Heo
2013-02-04 14:04   ` chas williams - CONTRACTOR
2013-02-04 17:06     ` Tejun Heo
2013-02-04 18:06       ` chas williams - CONTRACTOR
2013-02-04 18:37   ` [PATCH v3 " Tejun Heo
2013-02-03  1:20 ` [PATCH 10/62] drbd: " Tejun Heo
2013-02-03  1:20 ` [PATCH 11/62] dca: " Tejun Heo
2013-02-03  1:20 ` [PATCH 12/62] dmaengine: " Tejun Heo
2013-02-03  1:20 ` [PATCH 13/62] firewire: " Tejun Heo
2013-02-03 11:03   ` Stefan Richter
2013-02-03 11:18     ` Stefan Richter
2013-02-04 16:57   ` [PATCH 12.5/62] firewire: add minor number range check to fw_device_init() Tejun Heo
2013-02-04 18:15     ` Stefan Richter
2013-02-04 16:58   ` [PATCH v2 13/62] firewire: convert to idr_alloc() Tejun Heo
2013-02-04 18:16     ` Stefan Richter
2013-02-03  1:20 ` [PATCH 14/62] gpio: " Tejun Heo
2013-02-04 20:40   ` Linus Walleij
2013-02-03  1:20 ` [PATCH 15/62] drm: " Tejun Heo
2013-02-03  1:20 ` [PATCH 16/62] drm/exynos: " Tejun Heo
2013-02-03  1:20 ` [PATCH 17/62] drm/i915: " Tejun Heo
2013-02-04 14:53   ` Daniel Vetter
2013-02-03  1:20 ` [PATCH 18/62] drm/sis: " Tejun Heo
2013-02-03  1:20 ` [PATCH 19/62] drm/via: " Tejun Heo
2013-02-03  1:20 ` [PATCH 20/62] drm/vmwgfx: " Tejun Heo
2013-02-03  1:20 ` [PATCH 21/62] i2c: " Tejun Heo
2013-02-03  1:20 ` [PATCH 22/62] infiniband/core: " Tejun Heo
2013-02-04 16:43   ` [PATCH v2 " Tejun Heo
2013-02-05  0:07     ` Hefty, Sean
2013-02-03  1:20 ` [PATCH 23/62] infiniband/amso1100: " Tejun Heo
2013-02-03 14:36   ` Steve Wise
2013-02-03  1:20 ` [PATCH 24/62] infiniband/cxgb3: " Tejun Heo
2013-02-03 14:37   ` Steve Wise
2013-02-03  1:20 ` [PATCH 25/62] infiniband/cxgb4: " Tejun Heo
2013-02-03 14:18   ` Steve Wise
2013-02-03 14:28     ` Tejun Heo
2013-02-04 15:32   ` Steve Wise
2013-02-03  1:20 ` [PATCH 26/62] infiniband/ehca: " Tejun Heo
2013-02-03  1:20 ` [PATCH 27/62] infiniband/ipath: " Tejun Heo
2013-02-04 16:15   ` Marciniszyn, Mike
2013-02-04 16:18     ` Tejun Heo
2013-02-03  1:20 ` [PATCH 28/62] infiniband/mlx4: " Tejun Heo
2013-02-03  1:20 ` [PATCH 29/62] infiniband/ocrdma: " Tejun Heo
2013-02-03  1:20 ` [PATCH 30/62] infiniband/qib: " Tejun Heo
2013-02-03  1:20 ` [PATCH 31/62] dm: " Tejun Heo
2013-02-03  1:20 ` [PATCH 32/62] memstick: " Tejun Heo
2013-02-03  1:20 ` [PATCH 33/62] mfd: " Tejun Heo
2013-02-03 22:32   ` Samuel Ortiz
2013-02-03  1:20 ` [PATCH 34/62] misc/c2port: " Tejun Heo
2013-02-03  1:20 ` [PATCH 35/62] misc/tifm_core: " Tejun Heo
2013-02-03  1:20 ` [PATCH 36/62] mmc: " Tejun Heo
2013-02-03  1:20 ` [PATCH 37/62] mtd: " Tejun Heo
2013-02-04 13:09   ` Ezequiel Garcia
2013-02-03  1:20 ` [PATCH 38/62] i2c: " Tejun Heo
2013-02-03  1:25   ` [PATCH UPDATED 38/62] macvtap: " Tejun Heo
2013-02-03  1:20 ` [PATCH 39/62] ppp: " Tejun Heo
2013-02-03  1:20 ` [PATCH 40/62] power: " Tejun Heo
2013-02-03  3:46   ` Anton Vorontsov
2013-02-03  1:20 ` [PATCH 41/62] pps: " Tejun Heo
2013-02-03  1:20 ` [PATCH 42/62] remoteproc: " Tejun Heo
2013-02-03  1:20 ` [PATCH 43/62] rpmsg: " Tejun Heo
2013-02-03  1:20 ` [PATCH 44/62] scsi/bfa: " Tejun Heo
2013-02-03  1:20 ` [PATCH 45/62] scsi: " Tejun Heo
2013-02-03  1:20 ` [PATCH 46/62] target/iscsi: " Tejun Heo
2013-02-03  1:20 ` [PATCH 47/62] scsi/lpfc: " Tejun Heo
2013-02-11 22:46   ` James Smart
2013-02-03  1:20 ` [PATCH 48/62] thermal: " Tejun Heo
2013-02-03  1:20 ` [PATCH 49/62] uio: " Tejun Heo
2013-02-03  7:05   ` Greg Kroah-Hartman
2013-02-03  1:20 ` [PATCH 50/62] vfio: " Tejun Heo
2013-02-04 16:06   ` Alex Williamson
2013-02-04 16:48   ` [PATCH v2 " Tejun Heo
2013-02-03  1:20 ` [PATCH 51/62] dlm: " Tejun Heo
2013-02-03  1:20 ` [PATCH 52/62] inotify: " Tejun Heo
2013-02-03  1:20 ` [PATCH 53/62] ocfs2: " Tejun Heo
2013-02-03  1:20 ` [PATCH 54/62] ipc: " Tejun Heo
2013-02-03  1:20 ` [PATCH 55/62] cgroup: " Tejun Heo
2013-02-04  2:49   ` Li Zefan
2013-02-03  1:20 ` [PATCH 56/62] events: " Tejun Heo
2013-02-03  1:20 ` [PATCH 57/62] posix-timers: " Tejun Heo
2013-02-03  1:20 ` [PATCH 58/62] net/9p: " Tejun Heo
2013-02-03  1:21 ` [PATCH 59/62] mac80211: " Tejun Heo
2013-02-04 17:40   ` Johannes Berg
2013-02-04 17:42     ` Tejun Heo
2013-02-03  1:21 ` [PATCH 60/62] sctp: " Tejun Heo
2013-02-03 16:55   ` Neil Horman
2013-02-04 16:22   ` Vlad Yasevich
2013-02-04 16:37     ` Tejun Heo
2013-02-04 16:42   ` [PATCH v2 " Tejun Heo
2013-02-05 15:22     ` Neil Horman
2013-02-03  1:21 ` [PATCH 61/62] nfs4client: " Tejun Heo
2013-02-03  1:21 ` [PATCH 62/62] idr: deprecate idr_pre_get() and idr_get_new[_above]() Tejun Heo
2013-02-03 13:41 ` [PATCHSET] idr: implement idr_alloc() and convert existing users Eric W. Biederman
2013-02-03 14:13   ` Tejun Heo
2013-02-03 15:24     ` Eric W. Biederman
2013-02-03 15:47       ` Tejun Heo
2013-02-03 17:02 ` J. Bruce Fields
2013-02-04  0:15   ` J. Bruce Fields
2013-02-04 17:10     ` Tejun Heo
2013-02-04 17:11       ` Tejun Heo
2013-02-04 18:15         ` J. Bruce Fields
2013-03-21 14:06         ` J. Bruce Fields
2013-03-21 18:35           ` Tejun Heo
2013-03-26 15:19             ` Jeff Layton [this message]
2013-03-26 15:26               ` Tejun Heo
2013-03-26 16:30                 ` J. Bruce Fields
2013-03-26 16:33                   ` Tejun Heo
2013-03-26 16:36                     ` Tejun Heo
2013-03-26 16:52                       ` Jeff Layton
2013-02-04 17:16       ` J. Bruce Fields
2013-02-04 19:17 ` Tejun Heo
2013-02-04 19:54   ` Marciniszyn, Mike
2013-02-04 21:42     ` Tejun Heo
2013-02-04 22:25       ` Marciniszyn, Mike
2013-02-04 20:08   ` Marciniszyn, Mike
2013-02-04 21:43     ` Tejun Heo

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=20130326111936.550110bf@tlielax.poochiereds.net \
    --to=jlayton@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=axboe@kernel.dk \
    --cc=bfields@fieldses.org \
    --cc=ebiederm@xmission.com \
    --cc=jmorris@namei.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rusty@rustcorp.com.au \
    --cc=skinsbursky@parallels.com \
    --cc=tj@kernel.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 NNTP newsgroup(s).