Messages in this thread | | | Date | Thu, 25 Aug 2005 14:26:34 +0200 | From | Eric Dumazet <> | Subject | Re: [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/
| |