From: Lai Jiangshan <laijs@cn.fujitsu.com>
To: Alexey Dobriyan <adobriyan@gmail.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Paul Menage <menage@google.com>, Paul Jackson <pj@sgi.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/4] seq_file: don't call bitmap_scnprintf_len()
Date: Wed, 15 Oct 2008 09:35:03 +0800 [thread overview]
Message-ID: <48F548C7.6010609@cn.fujitsu.com> (raw)
In-Reply-To: <48F2F620.9020305@cn.fujitsu.com>
Lai Jiangshan wrote:
> Alexey Dobriyan wrote:
>> On Sun, Oct 12, 2008 at 05:29:17PM +0800, Lai Jiangshan wrote:
>>> "m->count + len < m->size" is true commonly, so bitmap_scnprintf()
>>> is commonly called. this fix saves a call to bitmap_scnprintf_len().
>> This saves a call if seq buffer is already full which is not a common
>> situation, so you're optimising for rare situations and adding branch
>> for common ones.
>
> Hi Alexey
>
> I think this saves a call if seq buffer is _not_ full after called.
>
> since calling bitmap_scnprintf() is the common situation. so we use
> the return value of bitmap_scnprintf() instead of bitmap_scnprintf_len().
>
> In old code bitmap_scnprintf_len() and bitmap_scnprintf() must be called
> commonly.
>
> Thanks Lai.
Hi, Alexey,
Have noticed this comment? I hold my ground, ;-)
And seq_cpumask_list(), seq_nodemask_list() are needed for print mask
safely, Should I send independent patches for them if we can't
make an agreement about this fix.
Lai
>
>>> --- a/fs/seq_file.c
>>> +++ b/fs/seq_file.c
>>> @@ -452,17 +452,18 @@ int seq_dentry(struct seq_file *m, struct dentry *dentry, char *esc)
>>>
>>> int seq_bitmap(struct seq_file *m, unsigned long *bits, unsigned int nr_bits)
>>> {
>>> - size_t len = bitmap_scnprintf_len(nr_bits);
>>> -
>>> - if (m->count + len < m->size) {
>>> - bitmap_scnprintf(m->buf + m->count, m->size - m->count,
>>> - bits, nr_bits);
>>> - m->count += len;
>>> - return 0;
>>> + if (m->count < m->size) {
>>> + int len = bitmap_scnprintf(m->buf + m->count,
>>> + m->size - m->count, bits, nr_bits);
>>> + if (m->count + len < m->size) {
>>> + m->count += len;
>>> + return 0;
>>> + }
>>> }
>>> m->count = m->size;
>>> return -1;
>>> }
>>> +EXPORT_SYMBOL(seq_bitmap);
>> Modular users, where are they?
>>
>>
>>
>
>
prev parent reply other threads:[~2008-10-15 1:37 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-12 9:29 [PATCH 1/4] seq_file: don't call bitmap_scnprintf_len() Lai Jiangshan
2008-10-13 6:38 ` Alexey Dobriyan
2008-10-13 7:17 ` Lai Jiangshan
2008-10-15 1:35 ` Lai Jiangshan [this message]
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=48F548C7.6010609@cn.fujitsu.com \
--to=laijs@cn.fujitsu.com \
--cc=adobriyan@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=menage@google.com \
--cc=pj@sgi.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 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.