[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
Eric Dumazet wrote:
> Nick Piggin a écrit :

>> 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)

True, I didn't notice that.

>> 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.

OK, well I would prefer you do the proper atomic operations throughout
where it "really matters" in file_table.c, and do your lazy synchronize
with just the sysctl exported value.

Unless the fs people had a problem with that.

And you may as well get rid of the atomic_inc_return which can be more
expensive on some platforms and doesn't buy you much.
Should be enough if you don't care about lost updates here, yeah?


SUSE Labs, Novell Inc.

Send instant messages to your online friends
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 16:54    [W:0.073 / U:46.952 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site