lkml.org 
[lkml]   [2005]   [Aug]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
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
>>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/

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