All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nick Piggin <nickpiggin@yahoo.com.au>
To: Jes Sorensen <jes@sgi.com>
Cc: Andrew Morton <akpm@osdl.org>, Keith Owens <kaos@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: Thu, 06 Jul 2006 04:26:04 +1000	[thread overview]
Message-ID: <44AC043C.70809@yahoo.com.au> (raw)
In-Reply-To: <44AB6AB3.5070407@sgi.com>

Jes Sorensen wrote:
> Nick Piggin wrote:
> 
>>Andrew Morton wrote:
>>
>>>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?).
> 
> 
> I suspect the real reason here is that there's now so many ways to get
> the processor ID that I cannot keep track of which one to use. Paul's
> mention of __raw_get_cpu_var() just confuses me even more.
> 
> So if anyone can give me a conclusive answer of which one to use, I'm
> happy to go there.
> 
> Granted I have a bias to avoid anything involving the preempt crap, but
> thats just me :)

Use smp_processor_id() unless you explicitly want a lazy CPU number,
and in that case use the raw_ version. Turning off preempt or preempt
debug options does the rest for you.

If you're just using the number to feed into per_cpu, then use the
appropriate get_cpu variant.

-- 
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com 

  reply	other threads:[~2006-07-05 18:26 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 ` 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-03 15:37 ` [PATCH] simplfy bh_lru_install Milton Miller
2006-07-03 15:37   ` Milton Miller
2006-07-04  5:32 ` [patch] reduce IPI noise due to /dev/cdrom open/close 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
2006-07-05  7:30       ` Jes Sorensen
2006-07-05 18:26         ` Nick Piggin [this message]
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=44AC043C.70809@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 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.