RE: boot time scheduling hile atomic

Any patch forthcomming soon?=20

-----Original Message-----
From: linuxppc-dev-bounces@ozlabs.org=20
[mailto:linuxppc-dev-bounces@ozlabs.org] On Behalf Of=20
Benjamin Herrenschmidt
Sent: Wednesday, March 16, 2005 16:29
To: Takeharu KATO
Cc: linuxppc-dev list
Subject: Re: boot time scheduling hile atomic
=20
On Wed, 2005-03-16 at 23:07 +0900, Takeharu KATO wrote:

quoted

Hi Benjamin:
=20
I can not figure out why my previous patch is more preferable than
later one.
Could you explain the reason of that please.

=20
There may be other kernel bits calling syscall, it sounds saner to
always make sure we don't reschedule when in atomic (though=20
it's dubious
that it's allowed to do syscalls in atomic regions, let's be safe
there).
=20
In fact, we are thinking about consolidating the syscall=20
return path and
the normal irq return path like we did on ppc64.
=20
Ben.
=20
=20
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
=20
=20

Hi

IMHO, it is more preferable to change kernel thread creation mechanism adapting to
other architecture(in stead of tweaking exception handling) to solve the issue at least.
Of course, cleaning up the exception codes to adapt to ppc64  is also preferable from
code maintenance view.

Anyway, please try to apply the patch as follow:
http://ozlabs.org/ppc32-patches/patch.pl?id=318

Rune Torgersen wrote:

Any patch forthcomming soon? 

quoted

-----Original Message-----
From: linuxppc-dev-bounces@ozlabs.org 
[mailto:linuxppc-dev-bounces@ozlabs.org] On Behalf Of 
Benjamin Herrenschmidt
Sent: Wednesday, March 16, 2005 16:29
To: Takeharu KATO
Cc: linuxppc-dev list
Subject: Re: boot time scheduling hile atomic

On Wed, 2005-03-16 at 23:07 +0900, Takeharu KATO wrote:

quoted

Hi Benjamin:

I can not figure out why my previous patch is more preferable than
later one.
Could you explain the reason of that please.

There may be other kernel bits calling syscall, it sounds saner to
always make sure we don't reschedule when in atomic (though 
it's dubious
that it's allowed to do syscalls in atomic regions, let's be safe
there).

In fact, we are thinking about consolidating the syscall 
return path and
the normal irq return path like we did on ppc64.

Ben.


_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev