From: Alex Tomas <alex@clusterfs.com>
To: Al Viro <viro@parcelfarce.linux.theplanet.co.uk>
Cc: LKML <linux-kernel@vger.kernel.org>,
linux-fsdevel@vger.kernel.org, alex@clusterfs.com
Subject: [RFC] parallel directory operations
Date: Sat, 19 Feb 2005 20:57:25 +0300 [thread overview]
Message-ID: <m34qg84em2.fsf@bzzz.home.net> (raw)
Good day Al and all
could you review couple patches that implement $subj
for vfs and tmpfs. In short the idea is that we can
protect operations taking semaphore related for set
of names. definitely, protection at vfs layer isn't
enough and filesystem will need to protect their own
structures by itself, but in some cases vfs patch is
enough. for example, tmpfs. during some loads one can
see quite high load in /tmp. being mounted as tmpfs
on big smp, we can get high contention on i_sem.
probably someone could try more-less real load?
I wrote simple program that spawn few processes, then
chdir to the given directory, then loops creating and
unlinking file. The test box is dual PIII-1GHz:
run 1: 2 processes create/unlink file on regular tmpfs
[root@bob root]# mount -t tmpfs none /test
[root@bob root]# (cd /test; time /root/crunl ./f 1000000 2)
#1998: 1000000 iterations, create/unlink ./f-0-1998
#1999: 1000000 iterations, create/unlink ./f-1-1999
#384: done
#384: done
wait for completion ... OK
real 0m36.224s
user 0m0.823s
sys 0m47.994s
run 2: 2 processes create/unlink file on tmpfs + pdirops
[root@bob root]# mount -t tmpfs -o pdirops none /test
[root@bob root]# (cd /test; time /root/crunl ./f 1000000 2)
#1992: 1000000 iterations, create/unlink ./f-0-1992
#1993: 1000000 iterations, create/unlink ./f-1-1993
#384: done
#384: done
wait for completion ... OK
real 0m15.108s
user 0m0.592s
sys 0m29.406s
run 3: 1 process creates/unlinks file on regular tmpfs
[root@bob root]# mount -t tmpfs none /test
[root@bob root]# (cd /test; time /root/crunl ./f 1000000 1)
#2004: 1000000 iterations, create/unlink ./f-0-2004
#384: done
wait for completion ... OK
real 0m11.950s
user 0m0.262s
sys 0m7.465s
run 4: 1 process creates/unlinks file on tmpf + pdirops
[root@bob root]# mount -t tmpfs -o pdirops none /test
[root@bob root]# (cd /test; time /root/crunl ./f 1000000 1)
#2009: 1000000 iterations, create/unlink ./f-0-2009
#384: done
wait for completion ... OK
real 0m8.047s
user 0m0.243s
sys 0m7.646s
2 processes creating/unlinking on regular tmpfs cause ~200K context switches:
procs memory swap io system cpu
r b w swpd free buff cache si so bi bo in cs us sy id
2 0 0 0 1005760 6616 10928 0 0 0 0 1007 215095 1 64 35
2 0 0 0 1005760 6616 10928 0 0 0 0 1007 213580 1 67 32
2 0 0 0 1005760 6616 10928 0 0 0 0 1007 214445 1 63 36
2 0 0 0 1005760 6616 10928 0 0 0 0 1007 216250 1 63 36
2 processes creating/unlinking on tmpfs + pdirops cause ~44 context switches:
procs memory swap io system cpu
r b w swpd free buff cache si so bi bo in cs us sy id
2 0 1 0 1001824 6632 10912 0 0 0 0 1008 41 2 98 0
2 0 2 0 1002144 6632 10912 0 0 0 0 1008 45 2 98 0
2 0 2 0 1001632 6632 10912 0 0 0 0 1007 47 2 98 0
the next benchmark is rename. two processes generate random name, create file,
generate new name, rename created file in new name and unlink:
run 5: regular tmpfs
[root@bob root]# mount -t tmpfs none /test
[root@bob root]# (cd /test; time /root/rndrename ./f 1000000 2)
#2036: 1000000 iterations
#2037: 1000000 iterations
wait for completion ... OK
real 1m22.381s
user 0m10.254s
sys 1m50.214s
run 6: tmpfs + pdirops
[root@bob root]# mount -t tmpfs -o pdirops none /test
[root@bob root]# (cd /test; time /root/rndrename ./f 1000000 2)
#2044: 1000000 iterations
#2045: 1000000 iterations
wait for completion ... OK
real 0m39.403s
user 0m9.411s
sys 1m8.626s
thanks, Alex
next reply other threads:[~2005-02-19 17:59 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-02-19 17:57 Alex Tomas [this message]
2005-02-19 18:04 ` [RFC] pdirops: vfs patch Alex Tomas
2005-02-20 23:35 ` Jan Blunck
2005-02-20 23:43 ` Alex Tomas
2005-02-19 18:05 ` [RFC] pdirops: tmpfs patch Alex Tomas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m34qg84em2.fsf@bzzz.home.net \
--to=alex@clusterfs.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=viro@parcelfarce.linux.theplanet.co.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).