Displaying 20 results from an estimated 315 matches for "idrs".
Did you mean:
idr
2012 Nov 03
2
Replacing NAs in long format
Hi,
I have the following data:
> data[1:20,c(1,2,20)]
idr schyear year
1 8 0
1 9 1
1 10 NA
2 4 NA
2 5 -1
2 6 0
2 7 1
2 8 2
2 9 3
2 10 4
2 11 NA
2 12 6
3 4 NA
3 5 -2
3 6 -1
3 7 0
3 8 1
3 9 2
3 10 3
3 11 NA
What I want to do is
2017 Nov 29
0
[PATCH v18 01/10] idr: add #include <linux/bug.h>
The <linux/bug.h> was removed from radix-tree.h by the following commit:
f5bba9d11a256ad2a1c2f8e7fc6aabe6416b7890.
Since that commit, tools/testing/radix-tree/ couldn't pass compilation
due to: tools/testing/radix-tree/idr.c:17: undefined reference to
WARN_ON_ONCE. This patch adds the bug.h header to idr.h to solve the
issue.
Signed-off-by: Wei Wang <wei.w.wang at intel.com>
Cc:
2013 Aug 28
2
[PATCH-v3 1/4] idr: Percpu ida
On Wed, 28 Aug 2013 13:44:54 -0700 Kent Overstreet <kmo at daterainc.com> wrote:
> > > > What guarantees that this wait will terminate?
> > >
> > > It seems fairly clear to me from the break statement a couple lines up;
> > > if we were passed __GFP_WAIT we terminate iff we succesfully allocated a
> > > tag. If we weren't passed
2013 Aug 28
2
[PATCH-v3 1/4] idr: Percpu ida
On Wed, 28 Aug 2013 13:44:54 -0700 Kent Overstreet <kmo at daterainc.com> wrote:
> > > > What guarantees that this wait will terminate?
> > >
> > > It seems fairly clear to me from the break statement a couple lines up;
> > > if we were passed __GFP_WAIT we terminate iff we succesfully allocated a
> > > tag. If we weren't passed
2017 Nov 30
2
[PATCH v18 01/10] idr: add #include <linux/bug.h>
On Wed, Nov 29, 2017 at 09:55:17PM +0800, Wei Wang wrote:
> The <linux/bug.h> was removed from radix-tree.h by the following commit:
> f5bba9d11a256ad2a1c2f8e7fc6aabe6416b7890.
>
> Since that commit, tools/testing/radix-tree/ couldn't pass compilation
> due to: tools/testing/radix-tree/idr.c:17: undefined reference to
> WARN_ON_ONCE. This patch adds the bug.h header to
2017 Nov 30
2
[PATCH v18 01/10] idr: add #include <linux/bug.h>
On Wed, Nov 29, 2017 at 09:55:17PM +0800, Wei Wang wrote:
> The <linux/bug.h> was removed from radix-tree.h by the following commit:
> f5bba9d11a256ad2a1c2f8e7fc6aabe6416b7890.
>
> Since that commit, tools/testing/radix-tree/ couldn't pass compilation
> due to: tools/testing/radix-tree/idr.c:17: undefined reference to
> WARN_ON_ONCE. This patch adds the bug.h header to
2013 Aug 28
0
[PATCH] percpu ida: Switch to cpumask_t, add some comments
Fixup patch, addressing Andrew's review feedback:
Signed-off-by: Kent Overstreet <kmo at daterainc.com>
---
include/linux/idr.h | 2 +-
lib/idr.c | 38 +++++++++++++++++++++-----------------
2 files changed, 22 insertions(+), 18 deletions(-)
diff --git a/include/linux/idr.h b/include/linux/idr.h
index f0db12b..cdf39be 100644
--- a/include/linux/idr.h
+++
2013 Aug 28
0
[PATCH-v3 1/4] idr: Percpu ida
On Wed, Aug 28, 2013 at 01:50:42PM -0700, Andrew Morton wrote:
> On Wed, 28 Aug 2013 13:44:54 -0700 Kent Overstreet <kmo at daterainc.com> wrote:
>
> > > > > What guarantees that this wait will terminate?
> > > >
> > > > It seems fairly clear to me from the break statement a couple lines up;
> > > > if we were passed __GFP_WAIT we
2013 Aug 20
5
[PATCH-v3 1/4] idr: Percpu ida
On Fri, 16 Aug 2013 23:09:06 +0000 "Nicholas A. Bellinger" <nab at linux-iscsi.org> wrote:
> From: Kent Overstreet <kmo at daterainc.com>
>
> Percpu frontend for allocating ids. With percpu allocation (that works),
> it's impossible to guarantee it will always be possible to allocate all
> nr_tags - typically, some will be stuck on a remote percpu
2013 Aug 20
5
[PATCH-v3 1/4] idr: Percpu ida
On Fri, 16 Aug 2013 23:09:06 +0000 "Nicholas A. Bellinger" <nab at linux-iscsi.org> wrote:
> From: Kent Overstreet <kmo at daterainc.com>
>
> Percpu frontend for allocating ids. With percpu allocation (that works),
> it's impossible to guarantee it will always be possible to allocate all
> nr_tags - typically, some will be stuck on a remote percpu
2013 Aug 16
0
[PATCH-v3 1/4] idr: Percpu ida
From: Kent Overstreet <kmo at daterainc.com>
Percpu frontend for allocating ids. With percpu allocation (that works),
it's impossible to guarantee it will always be possible to allocate all
nr_tags - typically, some will be stuck on a remote percpu freelist
where the current job can't get to them.
We do guarantee that it will always be possible to allocate at least
(nr_tags / 2)
2017 Dec 19
0
[PATCH v20 1/7] xbitmap: Introduce xbitmap
From: Matthew Wilcox <mawilcox at microsoft.com>
The eXtensible Bitmap is a sparse bitmap representation which is
efficient for set bits which tend to cluster. It supports up to
'unsigned long' worth of bits, and this commit adds the bare bones --
xb_set_bit(), xb_clear_bit() and xb_test_bit().
Signed-off-by: Wei Wang <wei.w.wang at intel.com>
Cc: Matthew Wilcox <mawilcox
2017 Dec 12
0
[PATCH v19 1/7] xbitmap: Introduce xbitmap
From: Matthew Wilcox <mawilcox at microsoft.com>
The eXtensible Bitmap is a sparse bitmap representation which is
efficient for set bits which tend to cluster. It supports up to
'unsigned long' worth of bits, and this commit adds the bare bones --
xb_set_bit(), xb_clear_bit() and xb_test_bit().
Signed-off-by: Wei Wang <wei.w.wang at intel.com>
Cc: Matthew Wilcox <mawilcox
2017 Dec 22
2
[PATCH v20 3/7 RESEND] xbitmap: add more operations
On 12/22/2017 05:03 AM, Matthew Wilcox wrote:
> OK, here's a rewrite of xbitmap.
>
> Compared to the version you sent:
> - xb_find_set() is the rewrite I sent out yesterday.
> - xb_find_clear() is a new implementation. I use the IDR_FREE tag to find
> clear bits. This led to me finding a bug in radix_tree_for_each_tagged().
> - xb_zero() is also a new
2017 Dec 22
2
[PATCH v20 3/7 RESEND] xbitmap: add more operations
On 12/22/2017 05:03 AM, Matthew Wilcox wrote:
> OK, here's a rewrite of xbitmap.
>
> Compared to the version you sent:
> - xb_find_set() is the rewrite I sent out yesterday.
> - xb_find_clear() is a new implementation. I use the IDR_FREE tag to find
> clear bits. This led to me finding a bug in radix_tree_for_each_tagged().
> - xb_zero() is also a new
2020 Feb 18
2
[PATCH] vhost: introduce vDPA based backend
On Fri, Jan 31, 2020 at 11:36:51AM +0800, Tiwei Bie wrote:
> +static int vhost_vdpa_alloc_minor(struct vhost_vdpa *v)
> +{
> + return idr_alloc(&vhost_vdpa.idr, v, 0, MINORMASK + 1,
> + GFP_KERNEL);
> +}
Please don't use idr in new code, use xarray directly
> +static int vhost_vdpa_probe(struct device *dev)
> +{
> + struct vdpa_device *vdpa = dev_to_vdpa(dev);
2020 Feb 18
2
[PATCH] vhost: introduce vDPA based backend
On Fri, Jan 31, 2020 at 11:36:51AM +0800, Tiwei Bie wrote:
> +static int vhost_vdpa_alloc_minor(struct vhost_vdpa *v)
> +{
> + return idr_alloc(&vhost_vdpa.idr, v, 0, MINORMASK + 1,
> + GFP_KERNEL);
> +}
Please don't use idr in new code, use xarray directly
> +static int vhost_vdpa_probe(struct device *dev)
> +{
> + struct vdpa_device *vdpa = dev_to_vdpa(dev);
2007 Mar 03
5
[PATCH] Compile issue with tools/libfsimage/iso9660
Compile issue with tools/libfsimage/iso9660
char vs unsigned char signedness causes a warning when compiling
iso9660 (xen-unstable). This patch changes the unsigned char * for
char *.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
diff -r 8eff89a69521 tools/libfsimage/iso9660/fsys_iso9660.c
--- a/tools/libfsimage/iso9660/fsys_iso9660.c Fri Mar 02 18:42:00 2007 -0500
+++
2015 Sep 17
2
DEFINE_IDA causing memory leaks? (was Re: [PATCH 1/2] virtio: fix memory leak of virtio ida cache layers)
On Wed, Sep 16, 2015 at 07:29:17PM -0500, Suman Anna wrote:
> The virtio core uses a static ida named virtio_index_ida for
> assigning index numbers to virtio devices during registration.
> The ida core may allocate some internal idr cache layers and
> an ida bitmap upon any ida allocation, and all these layers are
> truely freed only upon the ida destruction. The virtio_index_ida
2015 Sep 17
2
DEFINE_IDA causing memory leaks? (was Re: [PATCH 1/2] virtio: fix memory leak of virtio ida cache layers)
On Wed, Sep 16, 2015 at 07:29:17PM -0500, Suman Anna wrote:
> The virtio core uses a static ida named virtio_index_ida for
> assigning index numbers to virtio devices during registration.
> The ida core may allocate some internal idr cache layers and
> an ida bitmap upon any ida allocation, and all these layers are
> truely freed only upon the ida destruction. The virtio_index_ida