[prev in list] [next in list] [prev in thread] [next in thread] 

List:       fuse-devel
Subject:    Re: [fuse-devel] stat performance on multicore systems: measurements
From:       Anand Avati <anand.avati () gmail ! com>
Date:       2012-07-20 21:45:34
Message-ID: CAFboF2wASfcoHMMnk0bsYk3C6MQ7o2t1ogMK=znD3pxx5erSOw () mail ! gmail ! com
[Download RAW message or body]

On Wed, Jul 18, 2012 at 12:08 PM, Stefan Westerfeld <stefan@space.twc.de>wr=
ote:

>    Hi!
>
> As promised, I've created a test program that supports my theory that on
> multicore systems, fuse performance for stat() and other calls could be
> improved by scheduling the filesystem code that implements stat() and the
> userspace process that calls stat() on the same cpu.
>
> The first part of the test tries to figure out whether the userspace code
> and the filesystem part of the code run on the same cpu or not. Note that
> there is only one request at any single point in time, so the filesystem
> is essentially single threaded.
>
> The second part of the test then measures the stat() performance by
> calling it
> repeatedly; it computes how many stat() calls per second fuse can handle.
>
> These two measurements are repeated with a cpu affinity schedule setting
> that fixes the userspace code and the filesystem code on cpu 1. As I
> expected, this cpu affinity setting makes things significantly faster.
>
> Here are measurements for two multicore systems I have access to.
>
> ::::: AMD Phenom(tm) 9850 Quad-Core Processor
> ::::: Linux quadcorn 3.2.0-26-generic #41-Ubuntu SMP Thu Jun 14 17:49:24
> UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
>
> stefan@quadcorn:~/src/sandbox/cputestfs$ runme.sh
> make: F=C3=BCr das Ziel =C2=BBall=C2=AB ist nichts zu tun.
>
> #### without cpu affinity ####
>
> same  cpu (%)     0.00
> other cpu (%)   100.00
> ----------------------
> stat calls/s  23025.13
>
> #### with cpu affinity ####
>
> same  cpu (%)   100.00
> other cpu (%)     0.00
> ----------------------
> stat calls/s  44334.30
>
>
> ::::: AMD Athlon(tm) 64 X2 Dual Core Processor 6400+
> ::::: Linux ubuntu 3.2.0-26-generic #41-Ubuntu SMP Thu Jun 14 17:49:24 UTC
> 2012 x86_64 x86_64 x86_64 GNU/Linux
>
> stefan@ubuntu:~/src/sandbox/cputestfs$ runme.sh
> make: F=C3=BCr das Ziel =C2=BBall=C2=AB ist nichts zu tun.
>
> #### without cpu affinity ####
>
> same  cpu (%)     3.10
> other cpu (%)    96.90
> ----------------------
> stat calls/s  12164.21
>
> #### with cpu affinity ####
>
> same  cpu (%)   100.00
> other cpu (%)     0.00
> ----------------------
> stat calls/s  55163.82
>
> My test code can be downloaded at:
> http://space.twc.de/~stefan/fuse/cputestfs.tar.bz2
> It can be compiled & started by running the runme.sh script.
>
> I hope that in the future, fuse can be modified so that it avoids
> scheduling
> the filesystem code and the userspace code on different cpus. As the test
> indicates, this will improve the performance of stat() and probably all
> other
> filesystem calls.
>
>
FWIW, these are the results I see -

Proc: Intel(R) Xeon(R) CPU E5606 @ 2.13GHz Quad Core, Dual Socket (8 cores)
Kernel: Linux blackbox 2.6.32-220.17.1.el6.x86_64 #1 SMP Thu Apr 26
13:37:13 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux

#### without cpu affinity ####

same  cpu (%)     0.02
other cpu (%)    99.98
----------------------
stat calls/s  21482.23

#### with cpu affinity ####

same  cpu (%)   100.00
other cpu (%)     0.00
----------------------
stat calls/s  46138.05

The difference is quite significant (2x).

Avati
---------------------------------------------------------------------------=
---
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and =

threat landscape has changed and how IT managers can respond. Discussions =

will include endpoint security, mobile security and the latest in malware =

threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
fuse-devel mailing list
fuse-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fuse-devel
[prev in list] [next in list] [prev in thread] [next in thread]