> David Laight wrote:
> > IMHO I would have thought that 32bits would be enough...
> 
> Yes, it is more than enough on 32bit archs. Also, 'long' is actually
> 2^32 times bigger than 'int' on lp64 archs, so it's as good
> as reference counter as 32bit long for 32bit archs. All in all,
> 'long' should not be overflowable as reference counter on both LP32 and LP64
> archs.

My thought was that 32 bits would be enough on an LP64 system, maybe use
64bit on an ILP64 system.  Too many other things will explode before you
hit 64k references. I realise that someone once thought '65536 counts
will always be enough'  but you do need circa 2^30 processes before
a 32bit count will wrap.
> 
> > I presume you've seem the 16bit counter wrap - with obvious devistating
> > results...
> 
> Yes, I've seen the 16bit counter wrap.

Presumably on something like /dev/null on a process concurrency test of a
server task?  (21846 processes, 3 fd per process)
> 
> > However the extra 8 bytes per 'file' is probably a higher cost in kvm.
> 
> Yes, that too.

Also a question of how many cache lines the structure fits it.....

> Furthermore, 64bit arithmetic is costly on 32bit
> archs. For reference counters, it's entrirely supeflouous to have
> 64bit counters on 32bit archs.

And the 16bit arithmetic is also (probably) nasty!  Especially is gcc insists
on masking the high bits....

A thought of a cunning plan of wrapping back to 0x80000000 (ie using the
top bit as a 'has wrapped' state), on decrement to 0x80000000 you go and
look for a reference in one of the obvious places if you find one (and there
are plenty out there to find) if not you free the item.  But I can't quite
get the number to work without doing a extra compare. (I think you have to
check the decrement at 0x40000000 so it can be set back to 0x80000000.)

    David