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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
