Re: [PATCH] removes filp_count_lock and changes nr_files type toatomic_t

[Nick Piggin]

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/