All of lore.kernel.org
 help / color / mirror / Atom feed
From: george anzinger <george@mvista.com>
To: drummond@engr.valinux.com
Cc: Hubertus Franke <frankeh@us.ibm.com>,
	mingo@elte.hu, Linux Kernel List <linux-kernel@vger.kernel.org>,
	lse-tech@lists.sourceforge.net
Subject: Re: [Lse-tech] Bug in sys_sched_yield
Date: Thu, 12 Apr 2001 10:31:34 -0700	[thread overview]
Message-ID: <3AD5E676.CF1C1684@mvista.com> (raw)
In-Reply-To: <OFC3243AAE.31877E4B-ON85256A2B.006AE9C3@pok.ibm.com> <3AD5D311.5BFE39A6@mvista.com> <15061.56474.247739.99673@macallan.engr.valinux.com>

Walt Drummond wrote:
> 
> george anzinger writes:
> > Uh...  I do know about this map, but I wonder if it is at all needed.
> > What is the real difference between a logical cpu and the physical one.
> > Or is this only interesting if the machine is not Smp, i.e. all the cpus
> > are not the same?  It just seems to me that introducing an additional
> > mapping just slows things down and, if all the cpus are the same, does
> > not really do anything.  Of course, I am assuming that ALL usage would
> > be to the logical :)
> 
> Right.  That is not always the case.  IA32 is somewhat special. ;) The
> logical mapping allows you to, among other things, easily enumerate
> over the set of active processors without having to check if a
> processor exists at the current processor address.
> 
> The difference is apparent when the physical CPU ID is, say, an
> address on a processor bus, or worse, an address on a set of processor
> busses.  Take a look at the IA-64's smp.h.  The IA64 physical
> processor ID is a 64-bit structure that has to 8-bit ID's; an EID for
> what amounts to a "processor bus" ID and an ID that corresponds to a
> specific processor on a processor bus.  Together, they're a system
> global ID for a specific processor.  But there is no guarantee that
> the set of global ID's will be contiguous.
> 
> It's possible to have disjoint (non-contiguous) physical processor
> ID's if a processor bus is not completely populated, or there is an
> empty processor slot or odd processor numbering in firmware, or
> whatever.
> 
All that is cool.  Still, most places we don't really address the
processor, so the logical cpu number is all we need.  Places like
sched_yield, for example, should be using this, not the actual number,
which IMO should only be used when, for some reason, we NEED the hard
address of the cpu.  I don't think this ever has to leak out to the
common kernel code, or am i missing something here.

George

  reply	other threads:[~2001-04-12 17:34 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-04-11 19:31 Bug in sys_sched_yield Hubertus Franke
2001-04-11 20:12 ` Andrea Arcangeli
2001-04-12 16:08 ` [Lse-tech] " george anzinger
2001-04-12 16:49   ` Walt Drummond
2001-04-12 17:31     ` george anzinger [this message]
2001-04-16 16:03       ` Walt Drummond
     [not found] <OF33FEDED1.EDF6D260-ON85256A2D.006D99DE@pok.ibm.com>
2001-04-15 17:23 ` Kanoj Sarcar
2001-04-16 16:00 ` Walt Drummond

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=3AD5E676.CF1C1684@mvista.com \
    --to=george@mvista.com \
    --cc=drummond@engr.valinux.com \
    --cc=frankeh@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lse-tech@lists.sourceforge.net \
    --cc=mingo@elte.hu \
    /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.