[lkml]   [2006]   [Jan]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [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.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-01-31 21:22    [W:0.033 / U:7.240 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site