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.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/