[lkml]   [2005]   [Aug]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] removes filp_count_lock and changes nr_files type to atomic_t
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
> 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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-08-25 14:30    [W:0.087 / U:44.832 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site