RE: [RFC 00/10] implement alternative and much simpler id allocator

From: Rasmus Villemoes [mailto:li...@rasmusvillemoes.dk] > Nice work! A few random comments/questions: > > - It does add some complexity, but I think a few comments would make it > more digestable. I'm open to adding some comments ... I need some time between writing the code and writing the

RE: [RFC 00/10] implement alternative and much simpler id allocator

From: Rasmus Villemoes [mailto:li...@rasmusvillemoes.dk] > Nice work! A few random comments/questions: > > - It does add some complexity, but I think a few comments would make it > more digestable. I'm open to adding some comments ... I need some time between writing the code and writing the

Re: [RFC 00/10] implement alternative and much simpler id allocator

On Sat, Dec 17 2016, Matthew Wilcox wrote: > From: Matthew Wilcox >> From: Rasmus Villemoes [mailto:li...@rasmusvillemoes.dk] >> > This sounds good. I think there may still be a lot of users that never >> > allocate more than a handful of IDAs, making a 128 byte

Re: [RFC 00/10] implement alternative and much simpler id allocator

On Sat, Dec 17 2016, Matthew Wilcox wrote: > From: Matthew Wilcox >> From: Rasmus Villemoes [mailto:li...@rasmusvillemoes.dk] >> > This sounds good. I think there may still be a lot of users that never >> > allocate more than a handful of IDAs, making a 128 byte allocation still >> > somewhat

RE: [RFC 00/10] implement alternative and much simpler id allocator

From: Matthew Wilcox > From: Matthew Wilcox > > Heh, I was thinking about that too. The radix tree supports "exceptional > > entries" which have the bottom bit set. On a 64-bit machine, we could use > 62 > > of the bits in the radix tree root to store the ID bitmap. I'm a little > > wary of >

RE: [RFC 00/10] implement alternative and much simpler id allocator

From: Matthew Wilcox > From: Matthew Wilcox > > Heh, I was thinking about that too. The radix tree supports "exceptional > > entries" which have the bottom bit set. On a 64-bit machine, we could use > 62 > > of the bits in the radix tree root to store the ID bitmap. I'm a little > > wary of >

RE: [RFC 00/10] implement alternative and much simpler id allocator

From: Matthew Wilcox > From: Rasmus Villemoes [mailto:li...@rasmusvillemoes.dk] > > This sounds good. I think there may still be a lot of users that never > > allocate more than a handful of IDAs, making a 128 byte allocation still > > somewhat excessive. One thing I considered was (exactly as

RE: [RFC 00/10] implement alternative and much simpler id allocator

From: Matthew Wilcox > From: Rasmus Villemoes [mailto:li...@rasmusvillemoes.dk] > > This sounds good. I think there may still be a lot of users that never > > allocate more than a handful of IDAs, making a 128 byte allocation still > > somewhat excessive. One thing I considered was (exactly as

RE: [RFC 00/10] implement alternative and much simpler id allocator

From: Andrew Morton [mailto:a...@linux-foundation.org] > On Thu, 8 Dec 2016 02:22:55 +0100 Rasmus Villemoes > wrote: > > TL;DR: these patches save 250 KB of memory, with more low-hanging > > fruit ready to pick. > > > > While browsing through the lib/idr.c code, I

RE: [RFC 00/10] implement alternative and much simpler id allocator

From: Andrew Morton [mailto:a...@linux-foundation.org] > On Thu, 8 Dec 2016 02:22:55 +0100 Rasmus Villemoes > wrote: > > TL;DR: these patches save 250 KB of memory, with more low-hanging > > fruit ready to pick. > > > > While browsing through the lib/idr.c code, I noticed that the code at > >

RE: [RFC 00/10] implement alternative and much simpler id allocator

From: Rasmus Villemoes [mailto:li...@rasmusvillemoes.dk] > On Fri, Dec 16 2016, Matthew Wilcox wrote: > > Thanks for your work on this; you've really put some effort into > > proving your work has value. My motivation was purely aesthetic, but > > you've got some genuine

RE: [RFC 00/10] implement alternative and much simpler id allocator

From: Rasmus Villemoes [mailto:li...@rasmusvillemoes.dk] > On Fri, Dec 16 2016, Matthew Wilcox wrote: > > Thanks for your work on this; you've really put some effort into > > proving your work has value. My motivation was purely aesthetic, but > > you've got some genuine savings here (admittedly

Re: [RFC 00/10] implement alternative and much simpler id allocator

On Fri, Dec 16 2016, Matthew Wilcox wrote: > From: Andrew Morton [mailto:a...@linux-foundation.org] >> On Thu, 8 Dec 2016 02:22:55 +0100 Rasmus Villemoes >> wrote: >> > TL;DR: these patches save 250 KB of memory, with more low-hanging >> >

Re: [RFC 00/10] implement alternative and much simpler id allocator

On Fri, Dec 16 2016, Matthew Wilcox wrote: > From: Andrew Morton [mailto:a...@linux-foundation.org] >> On Thu, 8 Dec 2016 02:22:55 +0100 Rasmus Villemoes >> wrote: >> > TL;DR: these patches save 250 KB of memory, with more low-hanging >> > fruit ready to pick. >> > >> > While browsing through

Re: [RFC 00/10] implement alternative and much simpler id allocator

Hello, Matthew. On Mon, Dec 12, 2016 at 05:35:17PM +, Matthew Wilcox wrote: > I know the preload followed by preload_end looks wrong. I don't > think it's broken though. If we get preempted, then the worst > situation is that we'll end up with the memory we preallocated being > allocated to

Re: [RFC 00/10] implement alternative and much simpler id allocator

Hello, Matthew. On Mon, Dec 12, 2016 at 05:35:17PM +, Matthew Wilcox wrote: > I know the preload followed by preload_end looks wrong. I don't > think it's broken though. If we get preempted, then the worst > situation is that we'll end up with the memory we preallocated being > allocated to

RE: [RFC 00/10] implement alternative and much simpler id allocator

From: Tejun Heo [mailto:hte...@gmail.com] On Behalf Of Tejun Heo > Ah, yeah, great to see the silly implementation being replaced the > radix tree. ida_pre_get() looks suspicious tho. idr_preload() > immedicately being followed by idr_preload_end() probably is broken. > Maybe what we need is

RE: [RFC 00/10] implement alternative and much simpler id allocator

From: Tejun Heo [mailto:hte...@gmail.com] On Behalf Of Tejun Heo > Ah, yeah, great to see the silly implementation being replaced the > radix tree. ida_pre_get() looks suspicious tho. idr_preload() > immedicately being followed by idr_preload_end() probably is broken. > Maybe what we need is

Re: [RFC 00/10] implement alternative and much simpler id allocator

Hello, On Fri, Dec 09, 2016 at 02:01:40PM -0800, Andrew Morton wrote: > On Thu, 8 Dec 2016 02:22:55 +0100 Rasmus Villemoes > wrote: > > > TL;DR: these patches save 250 KB of memory, with more low-hanging > > fruit ready to pick. > > > > While browsing through the

Re: [RFC 00/10] implement alternative and much simpler id allocator

Hello, On Fri, Dec 09, 2016 at 02:01:40PM -0800, Andrew Morton wrote: > On Thu, 8 Dec 2016 02:22:55 +0100 Rasmus Villemoes > wrote: > > > TL;DR: these patches save 250 KB of memory, with more low-hanging > > fruit ready to pick. > > > > While browsing through the lib/idr.c code, I noticed

Re: [RFC 00/10] implement alternative and much simpler id allocator

On Thu, 8 Dec 2016 02:22:55 +0100 Rasmus Villemoes wrote: > TL;DR: these patches save 250 KB of memory, with more low-hanging > fruit ready to pick. > > While browsing through the lib/idr.c code, I noticed that the code at > the end of ida_get_new_above() probably

Re: [RFC 00/10] implement alternative and much simpler id allocator

On Thu, 8 Dec 2016 02:22:55 +0100 Rasmus Villemoes wrote: > TL;DR: these patches save 250 KB of memory, with more low-hanging > fruit ready to pick. > > While browsing through the lib/idr.c code, I noticed that the code at > the end of ida_get_new_above() probably doesn't work as intended:

Re: [RFC 00/10] implement alternative and much simpler id allocator

Hello, Rasmus. On Thu, Dec 08, 2016 at 02:22:55AM +0100, Rasmus Villemoes wrote: > TL;DR: these patches save 250 KB of memory, with more low-hanging > fruit ready to pick. > > While browsing through the lib/idr.c code, I noticed that the code at > the end of ida_get_new_above() probably doesn't

Re: [RFC 00/10] implement alternative and much simpler id allocator

Hello, Rasmus. On Thu, Dec 08, 2016 at 02:22:55AM +0100, Rasmus Villemoes wrote: > TL;DR: these patches save 250 KB of memory, with more low-hanging > fruit ready to pick. > > While browsing through the lib/idr.c code, I noticed that the code at > the end of ida_get_new_above() probably doesn't

[RFC 00/10] implement alternative and much simpler id allocator

TL;DR: these patches save 250 KB of memory, with more low-hanging fruit ready to pick. While browsing through the lib/idr.c code, I noticed that the code at the end of ida_get_new_above() probably doesn't work as intended: Most users of ida use it via ida_simple_get(), and that starts by

[RFC 00/10] implement alternative and much simpler id allocator

TL;DR: these patches save 250 KB of memory, with more low-hanging fruit ready to pick. While browsing through the lib/idr.c code, I noticed that the code at the end of ida_get_new_above() probably doesn't work as intended: Most users of ida use it via ida_simple_get(), and that starts by