On Sat, 29 Oct 2011 23:44:53 +0400
Pavel Shilovsky <piastry@xxxxxxxxxxx> wrote:
> 2011/10/29 Jeff Layton <jlayton@xxxxxxxxx>:
> ...
> >> + union {
> >> + struct {
> >> + atomic_t num_writes;
> >> + atomic_t num_reads;
> >> + atomic_t num_flushes;
> >> + atomic_t num_oplock_brks;
> >> + atomic_t num_opens;
> >> + atomic_t num_closes;
> >> + atomic_t num_deletes;
> >> + atomic_t num_mkdirs;
> >> + atomic_t num_posixopens;
> >> + atomic_t num_posixmkdirs;
> >> + atomic_t num_rmdirs;
> >> + atomic_t num_renames;
> >> + atomic_t num_t2renames;
> >> + atomic_t num_ffirst;
> >> + atomic_t num_fnext;
> >> + atomic_t num_fclose;
> >> + atomic_t num_hardlinks;
> >> + atomic_t num_symlinks;
> >> + atomic_t num_locks;
> >> + atomic_t num_acl_get;
> >> + atomic_t num_acl_set;
> >> + } cifs_stats;
> >> +#ifdef CONFIG_CIFS_SMB2
> >> + struct {
> >> + atomic_t smb2_com_sent[NUMBER_OF_SMB2_COMMANDS];
> >> + atomic_t smb2_com_fail[NUMBER_OF_SMB2_COMMANDS];
> >> + } smb2_stats;
> >
> > Is it really necessary to do this with atomics? Those can have
> > significant performance impact (TLB flushes, and we don't seem to need the
> > guarantees that they provide for simple counters like this. Perhaps
> > these should be switched to per-cpu variables or just plain ints?
>
> I am not sure I understand your idea to make it as int. What's about
> concurrency?
>
Sorry, I was reviewing these while on little sleep. We do need to worry
about concurrency here so ints are probably not appropriate (unless
these are already being incremented under a lock of some sort). Percpu
variables though would be ideal for this.
--
Jeff Layton <jlayton@xxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
