From: Thavatchai Makphaibulchoke <thavatchai.makpahibulchoke@hp.com>
To: Andreas Dilger <adilger@dilger.ca>
Cc: T Makphaibulchoke <tmac@hp.com>, Theodore Ts'o <tytso@mit.edu>,
"linux-ext4@vger.kernel.org List" <linux-ext4@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
aswin@hp.com
Subject: Re: [PATCH 2/2] fs/ext4/namei.c: reducing contention on s_orphan_lock mmutex
Date: Thu, 03 Oct 2013 17:08:00 -0600 [thread overview]
Message-ID: <524DF8D0.2080307@hp.com> (raw)
In-Reply-To: <139DD231-CA27-40C1-BBB5-B66B29640DC0@dilger.ca>
On 10/03/2013 06:41 PM, Andreas Dilger wrote:
>> + struct inode *next_inode;
>
> Stack space in the kernel is not so abundant that all (or any?) of these
> should get their own local variable.
>
>>
>> - if (!EXT4_SB(sb)->s_journal)
>
> Same here.
>
>
> Cheers, Andreas
Thanks Andreas for the comments. On larger machines with processors with lots of register, with the compiler optimization I don't think it matters whether stack variables or repeated common expressions are used. On smaller machines with processors with limited number of registers, this will be a problem. I'll fix these on my rework.
Thanks,
Mak.
next prev parent reply other threads:[~2013-10-03 23:08 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-02 15:36 [PATCH 1/2] fs/ext4: adding and initalizing new members of ext4_inode_info and ext4_sb_info T Makphaibulchoke
2013-10-02 15:36 ` [PATCH 2/2] fs/ext4/namei.c: reducing contention on s_orphan_lock mmutex T Makphaibulchoke
2013-10-03 2:05 ` Zheng Liu
2013-10-03 8:31 ` Thavatchai Makphaibulchoke
2013-10-04 0:41 ` Andreas Dilger
2013-10-03 23:08 ` Thavatchai Makphaibulchoke [this message]
2013-10-04 0:37 ` [PATCH 1/2] fs/ext4: adding and initalizing new members of ext4_inode_info and ext4_sb_info Andreas Dilger
2013-10-03 23:14 ` 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=524DF8D0.2080307@hp.com \
--to=thavatchai.makpahibulchoke@hp.com \
--cc=adilger@dilger.ca \
--cc=aswin@hp.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tmac@hp.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.