Re: [PATCH] removes filp_count_lock and changes nr_files type to atomic_t

[Nick Piggin <nickpiggin@yahoo.com.au>]

Eric Dumazet wrote:

> Furthermore, a lazy sync would mean to change sysctl proc_handler for 
> "file-nr" to perform a synchronize before calling proc_dointvec, this 
> would be really obscure.
>  

I was only using your terminology (ie. the 'lazy' synch after the
atomic is updated).

Actually, a better idea would be to make a specific sysctl handler
like Christoph said.

Unless you can show some improvement, it would better not to introduce
the racy hack (even if it is mostly harmless).

>> Unless the fs people had a problem with that.
>>
>> And you may as well get rid of the atomic_inc_return which can be more
>> expensive on some platforms and doesn't buy you much.
>>   atomic_inc;
>>   atomic_read;
>> Should be enough if you don't care about lost updates here, yeah?
>>
> 
> You mean :
> 
> atomic_inc(&counter);
> lazeyvalue = atomic_read(&counter);
> 
> instead of
> 
> lazeyvalue = atomic_inc_return(&counter);
> 

Yes.

> In fact I couldnt find one architecture where the later would be more 
> expensive.
> 

atomic_inc_return guarantees a memory barrier, while the former
statements do not. I'm fairly sure it will be more expensive on
a POWER5.

-- 
SUSE Labs, Novell Inc.

Send instant messages to your online friends http://au.messenger.yahoo.com