lkml.org 
[lkml]   [2002]   [Jan]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Problems with O(1) scheduler on non-x86 arch's

On Wed, 16 Jan 2002, James Bottomley wrote:

> I've been on a bug hunting expedition to try to make the new scheduler
> work with the voyager architecture port in kernel 2.4.2. I'm not sure
> if this is a side effect of the port or an intentional architecture
> shift. Some of the architecture ports (mine included) store the
> physical cpu number in p->processor (now p->cpu) rather than the
> logical one. I'm not sure if shifting to logical cpu numbering was
> behind the name change or not, but anyway, in case this is merely an
> oversight, the attached patch fixes the problem for me.

it's merely an oversight.

in the long term i think the correct approach would be to always store the
logical CPU number in p->cpu. Architectures that have some strange
physical numbering can always do a mapping themselves. This way we could
remove tons of cpu-id conversions from the generic code. And we are always
going to have these problems, now that the x86 SMP boot code renumbers
physical CPU ids to match the logical order.

i've checked the architectures, and besides your architecture it appears
that only Alpha does a non-identity ID conversion. So it would be much
cleaner for the generic kernel if we stored the logical CPU id in p->cpu,
and all SMP interfaces towards lowlevel SMP code used the logical CPU ID.

Ingo

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:23    [W:0.979 / U:0.412 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site