Re: [External] : Re: [PATCH 0/1] fsnotify: Check parent watches without child dentry flags

[Jan Kara]

On Fri 09-10-26 17:18:17, Partha Satapathy wrote:
> Hi Honza,
> 
> Thanks for suggesting this workload.
> The setup and before/after timing comparisons are below.
> 
> Architecture:                x86_64
> CPU(s):                      512
>   On-line CPU(s) list:       0-511
> 
> NUMA:
>   NUMA node(s):              2
>   NUMA node0 CPU(s):         0-127,256-383
>   NUMA node1 CPU(s):         128-255,384-511
> 
> Testcase :
> Using /dev/shm  tmpfs to create  private test directory.
> Create 1,024 files each fully populated with 4kb.
> Add IN_MODIFY inotify watch to the directory.
> Start a listener thread to read notifications and count queue overflows.
> Start X(1,2,4..1024) client threads; each opens a different file once.
> Wait until every client is ready, then release them together.
> Each client starts its timer and performs 1000000
> one-byte pwrite() at offset0 on its own file.
> Each client stops its timer and closes its file.
> Wait for all clients to finish, drain remaining notifications,
> and stop the listener.
> Print write times, throughput, notification count, and queue-overflow count.
> Close inotify and delete the test files and directory.
> 
> Note : File creation, open, close, and cleanup are outside the timed
> write loops.
> 
> Run 1:
> -------
> 
> | Clients | Before average time | After average time | Time change |
> |---:|---:|---:|---:|
> | 1 | 1.392 s | 1.484 s | +6.6% |
> | 2 | 2.205 s | 2.402 s | +8.9% |
> | 4 | 3.969 s | 3.644 s | −8.2% |
> | 8 | 5.851 s | 5.804 s | −0.8% |
> | 16 | 10.607 s | 11.538 s | +8.8% |
> | 32 | 21.093 s | 22.492 s | +6.6% |
> | 64 | 48.698 s | 49.576 s | +1.8% |
> | 128 | 100.208 s | 100.467 s | +0.3% |
> | 256 | 198.773 s | 197.669 s | −0.6% |
> | 512 | 400.056 s | 399.550 s | −0.1% |
> 
> 
> Run2 :
> --------
> 
> | Clients | Before average time | After average time | Time change |
> |---:|---:|---:|---:|
> | 1 | 1.491 s | 1.484 s | −0.4% |
> | 2 | 2.391 s | 2.402 s | +0.5% |
> | 4 | 4.050 s | 3.644 s | −10.0% |
> | 8 | 6.630 s | 5.804 s | −12.5% |
> | 16 | 11.931 s | 11.538 s | −3.3% |
> | 32 | 22.513 s | 22.492 s | −0.1% |
> | 64 | 50.231 s | 49.576 s | −1.3% |
> | 128 | 100.699 s | 100.467 s | −0.2% |
> | 256 | 198.771 s | 197.669 s | −0.6% |
> | 512 | 401.860 s | 399.550 s | −0.6% |
> | 1,024 | 803.812 s | 806.593 s | +0.3% |
> 
> 
> Positive means After Fix took longer; negative means faster.
> 
> 
> The measured write performance is broadly comparable before and after
> the fix, with no consistent substantial regression or progressively
> worsening slowdown as concurrency increases.
> 
> The differences vary between baseline batches: the increases at 16
> and 32 clients in the first comparison disappear or reverse in the
> second. At 128–1024 clients, average write times differ by approximately
> 0.6% or less. These shifts are consistent with run-to-run variation;
> the results do not show a persistent substantial slowdown from the fix.

Thanks for running these tests. Results are very interesting. Can you
please share your benchmarking program with me?  I'll check it and try to
play with it on my end. Thanks!

								Honza
-- 
Jan Kara <jack@xxxxxxxx>
SUSE Labs, CR