From: Thavatchai Makphaibulchoke <thavatchai.makpahibulchoke@hp.com>
To: Jan Kara <jack@suse.cz>
Cc: Theodore Ts'o <tytso@mit.edu>, linux-ext4@vger.kernel.org
Subject: Re: [PATCH 2/2] ext4: Reduce contention on s_orphan_lock
Date: Tue, 17 Jun 2014 22:38:32 -0600 [thread overview]
Message-ID: <53A117C8.3000207@hp.com> (raw)
In-Reply-To: <20140617092932.GB8622@quack.suse.cz>
On 06/17/2014 03:29 AM, Jan Kara wrote:
> Hum, looking at your test program source I'm not sure what do you mean.
> Your program first forks 'niteration' times and each process starts using a
> different directory. Then each of these processes forks 'procs' times and
> each of these processes will use a different file in the directory
> belonging to the parent. So what's the difference to just running
> 'niterations' * 'procs' processes? After some thought I guess the
> difference is in how time to run on each individual file contributes to the
> total average -
> (\sum_{i=1}^{procs} t_i)/procs
> in the first case you ran, where t_i is the time to run test for file i, and
> (max^{i=1}^{procs} t_i)
> in the second case. But what's the point?
>
The original test program generates orphan traffic on only a single file, which not only does not seem to be a fair comparison for the WM (with hashed mutexes) algorithm, does not seem to represent realistic load. The modified test's intention is to compare performance between the WM and WO (without hashed mutexes) under heavy orphan traffic on more than a single file.
Instead of running multiple copies of the original test in the background (for a short job we may not actually get overlapping traffic on different inodes), the modified test runs and start the excution, as close as possible to each other, of multiple copies of the original test.
The results of my test is the average, over ten runs, of the maximum time the original test takes to complete under certain number of processes and files. Of course, with one copy (niteration of 1), we get the equivalence of the original test.
> What do you exactly mean by 'journaling disabled'? Did you run ext4 in
> nojournal mode? That wouldn't really make sense because in nojournal mode
> all orphan list operations are skipped... So what did you really test?
>
Yes, sorry my fault disabling journaling, should also inhibit the orphan activities. Therefore there should not be any difference in performance between the two.
I just discovered that the two different branches I used do not have the same baseline. Let me recreate the two branches and redo my test. I'll get back with you with the results.
Sorry for the confusion.
Thanks,
Mak.
> Your numbers are interesting and seem to confirm that with really high
> contention it is advantageous to contend on smaller locks first (your
> hashed mutexes) and only after that on the global lock. But I'd like to
> hear answers to my previous questions before drawing any conclusions...
>
>
>
> Honza
>
next prev parent reply other threads:[~2014-06-18 4:41 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-15 20:17 [PATCH 0/2 v2] Improve orphan list scaling Jan Kara
2014-05-15 20:17 ` [PATCH 1/2] ext4: Use sbi in ext4_orphan_{add|del}() Jan Kara
2014-05-15 20:17 ` [PATCH 2/2] ext4: Reduce contention on s_orphan_lock Jan Kara
2014-05-20 3:23 ` Theodore Ts'o
2014-05-20 8:33 ` Thavatchai Makphaibulchoke
2014-05-20 9:18 ` Jan Kara
2014-05-20 13:57 ` Theodore Ts'o
2014-05-20 17:16 ` Thavatchai Makphaibulchoke
2014-06-02 17:45 ` Thavatchai Makphaibulchoke
2014-06-03 8:52 ` Jan Kara
2014-06-16 19:20 ` Thavatchai Makphaibulchoke
2014-06-17 9:29 ` Jan Kara
2014-06-18 4:38 ` Thavatchai Makphaibulchoke [this message]
2014-06-18 10:37 ` Jan Kara
2014-07-22 4:35 ` Thavatchai Makphaibulchoke
2014-07-23 8:15 ` Jan Kara
2014-05-19 14:50 ` [PATCH 0/2 v2] Improve orphan list scaling Theodore Ts'o
-- strict thread matches above, loose matches on Subject: below --
2014-05-20 12:45 [PATCH 0/2 v3] " Jan Kara
2014-05-20 12:45 ` [PATCH 2/2] ext4: Reduce contention on s_orphan_lock Jan Kara
2014-05-20 16:45 ` Thavatchai Makphaibulchoke
2014-05-20 21:03 ` Jan Kara
2014-05-20 23:27 ` Thavatchai Makphaibulchoke
2014-04-29 23:32 [PATCH 0/2] " Jan Kara
2014-04-29 23:32 ` [PATCH 2/2] " Jan Kara
2014-05-02 21:56 ` Thavatchai Makphaibulchoke
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=53A117C8.3000207@hp.com \
--to=thavatchai.makpahibulchoke@hp.com \
--cc=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
--cc=tytso@mit.edu \
/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).