Re: [PATCH] removes filp_count_lock and changes nr_files type to atomic_t

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Eric Dumazet wrote:

Furthermore, a lazy sync would mean to change sysctl proc_handler for "file-nr" to perform a synchronize before calling proc_dointvec, this would be really obscure.

I was only using your terminology (ie. the 'lazy' synch after the
atomic is updated).

Actually, a better idea would be to make a specific sysctl handler
like Christoph said.

Unless you can show some improvement, it would better not to introduce
the racy hack (even if it is mostly harmless).

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.
  atomic_inc;
  atomic_read;
Should be enough if you don't care about lost updates here, yeah?


You mean :

atomic_inc(&counter);
lazeyvalue = atomic_read(&counter);

instead of

lazeyvalue = atomic_inc_return(&counter);


Yes.

In fact I couldnt find one architecture where the later would be more expensive.


atomic_inc_return guarantees a memory barrier, while the former
statements do not. I'm fairly sure it will be more expensive on
a POWER5.

--
SUSE Labs, Novell Inc.

Send instant messages to your online friends http://au.messenger.yahoo.com -
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/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]
  Powered by Linux