2002-01-25 06:00:35

by The Doctor What

[permalink] [raw]
Subject: O(1) on powerpc....

I tried to compile the O(1) patch on the powerpc kernel (using
BenH's latest greatest). But it didn't work. It puked on the
counter and processor stuff in mk_def.c:4[01] in arch/powerpc/kernel

Is this patch just incompatable with the powerpc in some way, or is
it something that hasn't been addressed because Ingo has only ia32
systems at his disposal?

Ciao!

--
"By the pricking of my thumbs, something wicked this way comes."
--Shakespeare, MacBeth, IV:i

The Doctor What: Need I say more? http://docwhat.gerf.org/
[email protected] KF6VNC


2002-01-25 13:55:37

by Ingo Molnar

[permalink] [raw]
Subject: Re: O(1) on powerpc....


On Fri, 25 Jan 2002, The Doctor What wrote:

> I tried to compile the O(1) patch on the powerpc kernel (using BenH's
> latest greatest). But it didn't work. It puked on the counter and
> processor stuff in mk_def.c:4[01] in arch/powerpc/kernel
>
> Is this patch just incompatable with the powerpc in some way, or is it
> something that hasn't been addressed because Ingo has only ia32
> systems at his disposal?

i think Anton has patches to make PowerPC work - Anton?

Ingo

2002-01-25 14:08:02

by Robert Love

[permalink] [raw]
Subject: Re: O(1) on powerpc....

On Fri, 2002-01-25 at 10:52, Ingo Molnar wrote:

> i think Anton has patches to make PowerPC work - Anton?

We could do some things to generically make the other arches compatible
with the new scheduler, things like:

#define smp_processor_id() (current->processor)

still need to be fixed (to use ->cpu). I bet after a trivial
find/replace there is little left to do.

Robert Love

2002-01-25 14:15:42

by Ingo Molnar

[permalink] [raw]
Subject: Re: O(1) on powerpc....


On 25 Jan 2002, Robert Love wrote:

> We could do some things to generically make the other arches
> compatible with the new scheduler, things like:
>
> #define smp_processor_id() (current->processor)
>
> still need to be fixed (to use ->cpu). I bet after a trivial
> find/replace there is little left to do.

it's often more subtle then this. Every arch has to:

- implement the lowlevel task-migration mechanizm

- update the idle-thread code to use init_idle() + idle_startup_done().
Update the idle-thread priority changing bits.

- check context_switch() for IRQ-atomicity for being called with the
runqueue lock held - eg. ia64 re-enabled interrupts.

- add a definition of sched_find_first_bit()

- update any possible out-of-sync field offsets in entry.S.

so i'd not touch the trivial bits, because the hard bits will still be
unfixed, and who likes fixing the hard stuff only? :-)

Ingo