Re: [RFC] kernel/pid.c pid allocation wierdness

2007-03-16 Thread Eric W. Biederman
William Lee Irwin III <[EMAIL PROTECTED]> writes: > > On Fri, Mar 16, 2007 at 07:04:28AM -0600, Eric W. Biederman wrote: >> Grr. s/patricia tree/fib tree/. We use that in the networking for >> the forwarding information base and I got mis-remembered it. Anyway >> the interesting thing with the b

Re: [RFC] kernel/pid.c pid allocation wierdness

2007-03-16 Thread William Lee Irwin III
William Lee Irwin III <[EMAIL PROTECTED]> writes: >> I'd not mind something better than a hashtable. The fib tree may make >> more sense than anticipated. It's truly better to switch data structures >> completely than fiddle with e.g. hashtable sizes. However, bear in mind >> the degenerate space b

Re: [RFC] kernel/pid.c pid allocation wierdness

2007-03-16 Thread Eric W. Biederman
William Lee Irwin III <[EMAIL PROTECTED]> writes: > William Lee Irwin III <[EMAIL PROTECTED]> writes: >>> Radix trees' space behavior is extremely poor in sparsely-populated >>> index spaces. There is no way they would save space or even come close >>> to the current space footprint. > > On Wed, M

Re: [RFC] kernel/pid.c pid allocation wierdness

2007-03-16 Thread Pavel Emelianov
Eric Dumazet wrote: > On Friday 16 March 2007 11:57, Pavel Emelianov wrote: >> Oleg Nesterov wrote: >>> On 03/14, Eric W. Biederman wrote: Pavel Emelianov <[EMAIL PROTECTED]> writes: > Hi. > > I'm looking at how alloc_pid() works and can't understand > one (simple/stupid) thing

Re: [RFC] kernel/pid.c pid allocation wierdness

2007-03-16 Thread Dmitry Adamushko
On 16/03/07, Pavel Emelianov <[EMAIL PROTECTED]> wrote: Oleg Nesterov wrote: > On 03/14, Eric W. Biederman wrote: >> Pavel Emelianov <[EMAIL PROTECTED]> writes: >> >>> Hi. >>> >>> I'm looking at how alloc_pid() works and can't understand >>> one (simple/stupid) thing. >>> >>> It first kmem_cache_

Re: [RFC] kernel/pid.c pid allocation wierdness

2007-03-16 Thread Eric Dumazet
On Friday 16 March 2007 11:57, Pavel Emelianov wrote: > Oleg Nesterov wrote: > > On 03/14, Eric W. Biederman wrote: > >> Pavel Emelianov <[EMAIL PROTECTED]> writes: > >>> Hi. > >>> > >>> I'm looking at how alloc_pid() works and can't understand > >>> one (simple/stupid) thing. > >>> > >>> It first

Re: [RFC] kernel/pid.c pid allocation wierdness

2007-03-16 Thread Pavel Emelianov
Oleg Nesterov wrote: > On 03/14, Eric W. Biederman wrote: >> Pavel Emelianov <[EMAIL PROTECTED]> writes: >> >>> Hi. >>> >>> I'm looking at how alloc_pid() works and can't understand >>> one (simple/stupid) thing. >>> >>> It first kmem_cache_alloc()-s a strct pid, then calls >>> alloc_pidmap() and a

Re: [RFC] kernel/pid.c pid allocation wierdness

2007-03-15 Thread William Lee Irwin III
William Lee Irwin III <[EMAIL PROTECTED]> writes: >> Radix trees' space behavior is extremely poor in sparsely-populated >> index spaces. There is no way they would save space or even come close >> to the current space footprint. On Wed, Mar 14, 2007 at 10:54:07AM -0600, Eric W. Biederman wrote: >

Re: [RFC] kernel/pid.c pid allocation wierdness

2007-03-14 Thread Eric W. Biederman
William Lee Irwin III <[EMAIL PROTECTED]> writes: > On Wed, Mar 14, 2007 at 08:12:35AM -0600, Eric W. Biederman wrote: >> If we do dig into this more we need to consider a radix_tree to hold >> the pid values. That could replace both the pid map and the hash >> table, gracefully handle but large

Re: [RFC] kernel/pid.c pid allocation wierdness

2007-03-14 Thread Oleg Nesterov
On 03/14, Eric W. Biederman wrote: > Pavel Emelianov <[EMAIL PROTECTED]> writes: > > > Hi. > > > > I'm looking at how alloc_pid() works and can't understand > > one (simple/stupid) thing. > > > > It first kmem_cache_alloc()-s a strct pid, then calls > > alloc_pidmap() and at the end it taks a glob

Re: [RFC] kernel/pid.c pid allocation wierdness

2007-03-14 Thread William Lee Irwin III
On Wed, Mar 14, 2007 at 08:12:35AM -0600, Eric W. Biederman wrote: > If we do dig into this more we need to consider a radix_tree to hold > the pid values. That could replace both the pid map and the hash > table, gracefully handle but large and small pid counts, might > be a smidgin simpler, poss

Re: [RFC] kernel/pid.c pid allocation wierdness

2007-03-14 Thread William Lee Irwin III
On Wed, Mar 14, 2007 at 10:30:59AM +0300, Pavel Emelianov wrote: > I'm looking at how alloc_pid() works and can't understand > one (simple/stupid) thing. > It first kmem_cache_alloc()-s a strct pid, then calls > alloc_pidmap() and at the end it taks a global pidmap_lock() > to add new pid to hash.

Re: [RFC] kernel/pid.c pid allocation wierdness

2007-03-14 Thread Eric W. Biederman
Pavel Emelianov <[EMAIL PROTECTED]> writes: > Hi. > > I'm looking at how alloc_pid() works and can't understand > one (simple/stupid) thing. > > It first kmem_cache_alloc()-s a strct pid, then calls > alloc_pidmap() and at the end it taks a global pidmap_lock() > to add new pid to hash. > > The qu

[RFC] kernel/pid.c pid allocation wierdness

2007-03-13 Thread Pavel Emelianov
Hi. I'm looking at how alloc_pid() works and can't understand one (simple/stupid) thing. It first kmem_cache_alloc()-s a strct pid, then calls alloc_pidmap() and at the end it taks a global pidmap_lock() to add new pid to hash. The question is - why does alloc_pidmap() use at least two atomic op