On Tue, Jan 31, 2006 at 11:33:49AM +0100, Eric Dumazet wrote:
> Dipankar Sarma a écrit :
> >>Putting an atomic op into the file_free path?
> >
> >Here are some numbers from a 32-way (HT) P4 xeon box with kernbench -
> >
>
> Hi Dipankar, thank you very much for doing these tests.
>
> To have an idea of the number of files that are allocated/freed during a
> kernel build, I added 4 fields in struct files_stat.
>
> # cat /proc/sys/fs/file-nr
> 153 0 206071 153 755767 755620 5119
>
> So thats (755767-39169)/(4*60+56) = 2420 files opened per second.
>
> Number of changes on central atomic_t was :
> (5119-1131)/(4*60+56) = 13 per second.
>
> 13 atomic ops per second (instead of 2420*2 per second if I had one
> atomic_t as in your patch), this is certainly not something we can notice
> in a typical SMP machine... maybe on a big NUMA machine it could be
> different ?
Depends on what you call big :) The one I ran on is a 2-node NUMA
16(32)-way with HT. I can't find anything bigger than this
in our server farm. On a 8-way ppc64 box too, there was no difference
at all.
Can you think of some non-microbenchish workload with more open/sec ?
I privately pointed out this thread to John Hawkes from SGI to see
if they care about the potential issues. In the mean while,
I will investigate some more.
Thanks
Dipankar
-
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]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
