From: Thavatchai Makphaibulchoke <thavatchai.makpahibulchoke@hp.com>
To: Jan Kara <jack@suse.cz>, T Makphaibulchoke <tmac@hp.com>
Cc: linux-ext4@vger.kernel.org
Subject: Re: [PATCH 0/2] ext4: Reduce contention on s_orphan_lock
Date: Fri, 02 May 2014 15:56:56 -0600 [thread overview]
Message-ID: <536414A8.2040506@hp.com> (raw)
In-Reply-To: <1398814353-11904-1-git-send-email-jack@suse.cz>
On 04/29/2014 05:32 PM, Jan Kara wrote:
>
> Hello,
>
> so I finally got to looking into your patches for reducing contention
> on s_orphan_lock. AFAICT these two patches (the first one is just a
> small cleanup) should have the same speed gain as the patches you wrote
> and they are simpler. Can you give them a try please? Thanks!
>
> Honza
>
I applied your patch and ran aim7 on both the 80 and 120 core count machines. There are aim7 workloads that your patch does show some performance improvement. Unfortunately in general, it does not have the same performance level as my original patch, especially with high user count, 500 or more.
As for the hashed mutex used in my patch to serialize orphan operation within a single node, even if I agree with you that with existing code it is not required, I don't believe that you can count on that in the future. I believe that is also your concern, as you also added comment indicating the requirement of the i_mutex in your patch.
In terms of maintainability, I do not believe simply relying on warning in a comment is sufficient. On top of that with this new requirement, we are unnecessarily coupling the orphan operations to i_mutex, adding more contention to it. This would likely to cause performance regression, as my experiment in responding to your earlier comment on my patch did show some regression when using i_mutex for serialization of orphan operations within a single node (adding code to lock the if it is not already locked).
I still believe having a different mutex for orphan operation serialization is a better and safer alternative. From my experiment so far (I'm still verifying this), it may even help improving the performance by spreading out the contention on the s_orphan_mutex.
Please also see my response to patch 2/2 for comments on the actual code.
Thanks,
Mak.
next prev parent reply other threads:[~2014-05-02 21:58 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-29 23:32 [PATCH 0/2] ext4: Reduce contention on s_orphan_lock Jan Kara
2014-04-29 23:32 ` [PATCH 1/2] ext4: Use sbi in ext4_orphan_del() Jan Kara
2014-04-29 23:32 ` [PATCH 2/2] ext4: Reduce contention on s_orphan_lock Jan Kara
2014-05-02 21:56 ` Thavatchai Makphaibulchoke
2014-05-02 21:56 ` Thavatchai Makphaibulchoke [this message]
2014-05-06 11:49 ` [PATCH 0/2] " Jan Kara
2014-05-09 6:24 ` 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=536414A8.2040506@hp.com \
--to=thavatchai.makpahibulchoke@hp.com \
--cc=jack@suse.cz \
--cc=linux-ext4@vger.kernel.org \
--cc=tmac@hp.com \
/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).