[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <48F2F620.9020305@cn.fujitsu.com>
Date: Mon, 13 Oct 2008 15:17:52 +0800
From: Lai Jiangshan <laijs@...fujitsu.com>
To: Alexey Dobriyan <adobriyan@...il.com>
CC: Andrew Morton <akpm@...ux-foundation.org>,
Paul Menage <menage@...gle.com>, Paul Jackson <pj@....com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/4] seq_file: don't call bitmap_scnprintf_len()
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.
>
>> --- 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?
>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists