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

[Eric Dumazet <dada1@cosmosbay.com>]

Nick Piggin a écrit :
> On Thu, 2005-08-25 at 12:41 +0200, Eric Dumazet wrote:
> 
> 
>>OK, here is a new clean patch that address this problem (nothing assumed about 
>>atomics)
>>
> 
> 
> Would you just be able to add the atomic sysctl handler that
> Christoph suggested?
> 

Quite a lot of work indeed, and it would force to convert 3 int (nr_files, 
nr_free_files, max_files) to 3 atomic_t. I feel bad introducing a lot of 
sysctl rework for a tiny change (removing filp_count_lock)

> This introduces lost update problems. 2 CPUs may store to nr_files
> in the opposite order that they incremented atomic_nr_files.
> 

That's true, and the difference can be relatively important in case of preemption.

Each time the true and correct value  (atomic_nr_files) is updated, a copy is 
done on nr_files : as nr_files is only used to be a guard value against too 
many file allocations, a somewhat 'lazy' value has no impact at all.

> It is not terribly bad, because the drift is not cumulative and the
> field can't go negative... but its just ugly to add this hack
> because there is no atomic sysctl handler.
> 
> Eliminating the cli/sti is a good idea though, I think.
>