O(1) on powerpc....

O(1) on powerpc....

[The Doctor What]

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/
docwhat@gerf.org                                                   KF6VNC

Re: O(1) on powerpc....

[Robert Love]

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

Re: O(1) on powerpc....

[Ingo Molnar]

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

Re: O(1) on powerpc....

[Ingo Molnar]

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