From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Andrew Morton <akpm@osdl.org>
Cc: Keith Owens <kaos@sgi.com>,
jes@sgi.com, torvalds@osdl.org, viro@zeniv.linux.org.uk,
linux-kernel@vger.kernel.org
Subject: Re: [patch] reduce IPI noise due to /dev/cdrom open/close
Date: Wed, 05 Jul 2006 03:33:01 +1000 [thread overview]
Message-ID: <44AAA64D.8030907@yahoo.com.au> (raw)
In-Reply-To: <20060703234134.786944f1.akpm@osdl.org>
Andrew Morton wrote:
> On Tue, 04 Jul 2006 15:32:19 +1000
> Keith Owens <kaos@sgi.com> wrote:
>>Why raw_smp_processor_id? That normally indicates code that wants a
>>lazy cpu number, but this code requires the exact cpu number, IMHO
>>using raw_smp_processor_id is confusing. smp_processor_id can safely
>>be used here, bh_lru_lock has disabled irq or preempt.
>
>
> I expect raw_smp_processor_id() is used here as a a microoptimisation -
> avoid a might_sleep() which obviously will never trigger.
A microoptimisation because they've turned on DEBUG_PREEMPT and found
that smp_processor_id slows down? ;) Wouldn't it be better to just stick
to the normal rules (ie. what Keith said)?
It may be obvious in this case (though that doesn't help people who make
obvious mistakes, or mismerge patches) but this just seems like a nasty
precedent to set (or has it already been?).
>
> But I think it'd be better to do just a single raw_smp_processor_id() for
> this entire function:
>
> static void bh_lru_install(struct buffer_head *bh)
> {
> struct buffer_head *evictee = NULL;
> struct bh_lru *lru;
> + int cpu;
>
> check_irqs_on();
> bh_lru_lock();
> + cpu = raw_smp_processor_id();
> - lru = &__get_cpu_var(bh_lrus);
> + lru = per_cpu(bh_lrus, cpu);
>
> etcetera.
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
next prev parent reply other threads:[~2006-07-04 17:34 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-03 15:33 [patch] reduce IPI noise due to /dev/cdrom open/close Jes Sorensen
2006-07-03 15:37 ` [PATCH] simplfy bh_lru_install Milton Miller
2006-07-03 15:37 ` Milton Miller
2006-07-03 15:37 ` [patch] reduce IPI noise due to /dev/cdrom open/close Milton Miller
2006-07-04 7:47 ` Jes Sorensen
2006-07-04 7:53 ` Arjan van de Ven
2006-07-04 8:12 ` Jes Sorensen
2006-07-04 8:23 ` Arjan van de Ven
2006-07-04 8:33 ` Jes Sorensen
2006-07-04 13:02 ` Helge Hafting
2006-07-04 8:42 ` Milton Miller
2006-07-04 8:59 ` Jes Sorensen
2006-07-04 9:30 ` Milton Miller
2006-07-04 5:32 ` Keith Owens
2006-07-04 6:41 ` Andrew Morton
2006-07-04 7:51 ` Jes Sorensen
2006-07-04 9:13 ` Milton Miller
2006-07-04 17:33 ` Nick Piggin [this message]
2006-07-05 7:30 ` Jes Sorensen
2006-07-05 18:26 ` Nick Piggin
2006-07-05 0:10 ` Paul Mackerras
2006-07-04 7:49 ` Jes Sorensen
2006-07-04 8:04 ` Andrew Morton
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=44AAA64D.8030907@yahoo.com.au \
--to=nickpiggin@yahoo.com.au \
--cc=akpm@osdl.org \
--cc=jes@sgi.com \
--cc=kaos@sgi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@osdl.org \
--cc=viro@zeniv.linux.org.uk \
/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