Messages in this thread |  | | | Date | Wed, 1 Feb 2006 01:49:16 +0530 | | From | Dipankar Sarma <> | | Subject | Re: [patch 2/2] fix file counting |
| |
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 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/
|  |