David Mosberger wrote:
On Tue, 12 Apr 2005 12:12:45 +1000, Nick Piggin <[EMAIL PROTECTED]> said:
>> Now, Ingo says that the order is reversed with his patch, i.e.,
>> switch_mm() happens after switch_to(). That means flush_tlb_mm()
>> may now see a current->active_mm which hasn't really
> On Tue, 12 Apr 2005 08:42:53 +0200, Ingo Molnar <[EMAIL PROTECTED]> said:
Ingo> * David Mosberger <[EMAIL PROTECTED]> wrote:
>> Now, Ingo says that the order is reversed with his patch, i.e.,
>> switch_mm() happens after switch_to(). That means flush_tlb_mm()
>> may now see a
> On Tue, 12 Apr 2005 12:12:45 +1000, Nick Piggin <[EMAIL PROTECTED]> said:
>> Now, Ingo says that the order is reversed with his patch, i.e.,
>> switch_mm() happens after switch_to(). That means flush_tlb_mm()
>> may now see a current->active_mm which hasn't really been
>> activated
* David Mosberger <[EMAIL PROTECTED]> wrote:
> Now, Ingo says that the order is reversed with his patch, i.e.,
> switch_mm() happens after switch_to(). That means flush_tlb_mm() may
> now see a current->active_mm which hasn't really been activated yet.
> That should be OK since it would
* David Mosberger [EMAIL PROTECTED] wrote:
Now, Ingo says that the order is reversed with his patch, i.e.,
switch_mm() happens after switch_to(). That means flush_tlb_mm() may
now see a current-active_mm which hasn't really been activated yet.
That should be OK since it would just mean
On Tue, 12 Apr 2005 12:12:45 +1000, Nick Piggin [EMAIL PROTECTED] said:
Now, Ingo says that the order is reversed with his patch, i.e.,
switch_mm() happens after switch_to(). That means flush_tlb_mm()
may now see a current-active_mm which hasn't really been
activated yet.
Nick If
On Tue, 12 Apr 2005 08:42:53 +0200, Ingo Molnar [EMAIL PROTECTED] said:
Ingo * David Mosberger [EMAIL PROTECTED] wrote:
Now, Ingo says that the order is reversed with his patch, i.e.,
switch_mm() happens after switch_to(). That means flush_tlb_mm()
may now see a current-active_mm
David Mosberger wrote:
On Tue, 12 Apr 2005 12:12:45 +1000, Nick Piggin [EMAIL PROTECTED] said:
Now, Ingo says that the order is reversed with his patch, i.e.,
switch_mm() happens after switch_to(). That means flush_tlb_mm()
may now see a current-active_mm which hasn't really been
On Mon, 2005-04-11 at 18:06 -0700, David Mosberger wrote:
> I had to refresh my memory with a quick Google search that netted [1]
> (look for "Disable interrupts during context switch"). Actually, it
> wasn't really a deadlock, but rather a livelock, since a CPU got stuck
> on an infinite
> On Sun, 10 Apr 2005 08:43:24 +0200, Ingo Molnar <[EMAIL PROTECTED]> said:
Ingo> * David S. Miller <[EMAIL PROTECTED]> wrote:
>> > Yes, of course. The deadlock was due to context-switching, not
>> > switch_mm() per se. Hopefully someone else beats me to
>> remembering > the
On Sun, 10 Apr 2005 08:43:24 +0200, Ingo Molnar [EMAIL PROTECTED] said:
Ingo * David S. Miller [EMAIL PROTECTED] wrote:
Yes, of course. The deadlock was due to context-switching, not
switch_mm() per se. Hopefully someone else beats me to
remembering the details before Monday.
On Mon, 2005-04-11 at 18:06 -0700, David Mosberger wrote:
I had to refresh my memory with a quick Google search that netted [1]
(look for Disable interrupts during context switch). Actually, it
wasn't really a deadlock, but rather a livelock, since a CPU got stuck
on an infinite
On Sat, Apr 09, 2005 at 03:46:12PM -0700, David S. Miller wrote:
> On Sat, 09 Apr 2005 19:22:23 +1000
> Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
>
> > ppc64 already has a local_irq_save/restore in switch_to, around the low
> > level asm bits, so it should be fine.
>
> Sparc64
* David S. Miller <[EMAIL PROTECTED]> wrote:
> > Yes, of course. The deadlock was due to context-switching, not
> > switch_mm() per se. Hopefully someone else beats me to remembering
> > the details before Monday.
>
> Sparc64 has a deadlock because we hold mm->page_table_lock during
>
* David S. Miller [EMAIL PROTECTED] wrote:
Yes, of course. The deadlock was due to context-switching, not
switch_mm() per se. Hopefully someone else beats me to remembering
the details before Monday.
Sparc64 has a deadlock because we hold mm-page_table_lock during
switch_mm(). I
On Sat, Apr 09, 2005 at 03:46:12PM -0700, David S. Miller wrote:
On Sat, 09 Apr 2005 19:22:23 +1000
Benjamin Herrenschmidt [EMAIL PROTECTED] wrote:
ppc64 already has a local_irq_save/restore in switch_to, around the low
level asm bits, so it should be fine.
Sparc64 essentially does as
On Sat, 9 Apr 2005 00:15:37 -0700
David Mosberger <[EMAIL PROTECTED]> wrote:
> Yes, of course. The deadlock was due to context-switching, not
> switch_mm() per se. Hopefully someone else beats me to remembering
> the details before Monday.
Sparc64 has a deadlock because we hold
On Sat, 09 Apr 2005 19:22:23 +1000
Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote:
> ppc64 already has a local_irq_save/restore in switch_to, around the low
> level asm bits, so it should be fine.
Sparc64 essentially does as well. In fact, it uses an IRQ disable
which is stronger than
On Sat, 2005-04-09 at 06:38 +0200, Ingo Molnar wrote:
> * Luck, Tony <[EMAIL PROTECTED]> wrote:
>
> > >tested on x86, and all other arches should work as well, but if an
> > >architecture has irqs-off assumptions in its switch_to() logic
> > >it might break. (I havent found any but there may
> On Sat, 9 Apr 2005 09:07:38 +0200, Ingo Molnar <[EMAIL PROTECTED]> said:
Ingo> * David Mosberger-Tang <[EMAIL PROTECTED]> wrote:
>> > The ia64_switch_to() code includes a section that can change a
>> > pinned MMU mapping (when the stack for the new process is in a
>> > different
Ingo Molnar wrote:
* Nick Piggin <[EMAIL PROTECTED]> wrote:
I did propose doing unconditionally unlocked switches a while back
when my patch first popped up - you were against it then, but I guess
you've had second thoughts?
the reordering of switch_to() and the switch_mm()-related logic was
* David Mosberger-Tang <[EMAIL PROTECTED]> wrote:
> > The ia64_switch_to() code includes a section that can change a
> > pinned MMU mapping (when the stack for the new process is in a
> > different granule from the stack for the old process). The code
> > beyond the ".map" label in
* Nick Piggin <[EMAIL PROTECTED]> wrote:
> Well that does look like a pretty good cleanup. It certainly is the
> final step in freeing complex architecture switching code from
> entanglement with scheduler internal locking, and unifies the locking
> scheme.
>
> I did propose doing
> Tony:
>> Ingo:
>> tested on x86, and all other arches should work as well, but if an
>> architecture has irqs-off assumptions in its switch_to() logic it
>> might break. (I havent found any but there may such assumptions.)
> The ia64_switch_to() code includes a section that can change
Ingo Molnar wrote:
* Luck, Tony <[EMAIL PROTECTED]> wrote:
tested on x86, and all other arches should work as well, but if an
architecture has irqs-off assumptions in its switch_to() logic
it might break. (I havent found any but there may such assumptions.)
The ia64_switch_to() code includes a
Ingo Molnar wrote:
* Luck, Tony [EMAIL PROTECTED] wrote:
tested on x86, and all other arches should work as well, but if an
architecture has irqs-off assumptions in its switch_to() logic
it might break. (I havent found any but there may such assumptions.)
The ia64_switch_to() code includes a
Tony:
Ingo:
tested on x86, and all other arches should work as well, but if an
architecture has irqs-off assumptions in its switch_to() logic it
might break. (I havent found any but there may such assumptions.)
The ia64_switch_to() code includes a section that can change a
pinned
* Nick Piggin [EMAIL PROTECTED] wrote:
Well that does look like a pretty good cleanup. It certainly is the
final step in freeing complex architecture switching code from
entanglement with scheduler internal locking, and unifies the locking
scheme.
I did propose doing unconditionally
* David Mosberger-Tang [EMAIL PROTECTED] wrote:
The ia64_switch_to() code includes a section that can change a
pinned MMU mapping (when the stack for the new process is in a
different granule from the stack for the old process). The code
beyond the .map label in
Ingo Molnar wrote:
* Nick Piggin [EMAIL PROTECTED] wrote:
I did propose doing unconditionally unlocked switches a while back
when my patch first popped up - you were against it then, but I guess
you've had second thoughts?
the reordering of switch_to() and the switch_mm()-related logic was
On Sat, 9 Apr 2005 09:07:38 +0200, Ingo Molnar [EMAIL PROTECTED] said:
Ingo * David Mosberger-Tang [EMAIL PROTECTED] wrote:
The ia64_switch_to() code includes a section that can change a
pinned MMU mapping (when the stack for the new process is in a
different granule from the
On Sat, 2005-04-09 at 06:38 +0200, Ingo Molnar wrote:
* Luck, Tony [EMAIL PROTECTED] wrote:
tested on x86, and all other arches should work as well, but if an
architecture has irqs-off assumptions in its switch_to() logic
it might break. (I havent found any but there may such
On Sat, 09 Apr 2005 19:22:23 +1000
Benjamin Herrenschmidt [EMAIL PROTECTED] wrote:
ppc64 already has a local_irq_save/restore in switch_to, around the low
level asm bits, so it should be fine.
Sparc64 essentially does as well. In fact, it uses an IRQ disable
which is stronger than
On Sat, 9 Apr 2005 00:15:37 -0700
David Mosberger [EMAIL PROTECTED] wrote:
Yes, of course. The deadlock was due to context-switching, not
switch_mm() per se. Hopefully someone else beats me to remembering
the details before Monday.
Sparc64 has a deadlock because we hold mm-page_table_lock
* Luck, Tony <[EMAIL PROTECTED]> wrote:
> >tested on x86, and all other arches should work as well, but if an
> >architecture has irqs-off assumptions in its switch_to() logic
> >it might break. (I havent found any but there may such assumptions.)
>
> The ia64_switch_to() code includes a
>tested on x86, and all other arches should work as well, but if an
>architecture has irqs-off assumptions in its switch_to() logic
>it might break. (I havent found any but there may such assumptions.)
The ia64_switch_to() code includes a section that can change a pinned
MMU mapping (when the
the scheduler still has a complex maze of locking in the *arch_switch()
/ *lock_switch() code. Different arches do it differently, creating
diverging context-switch behavior. There are now 3 variants: fully
locked, unlocked but irqs-off, unlocked and irqs-on.
Nick has cleaned them up in
the scheduler still has a complex maze of locking in the *arch_switch()
/ *lock_switch() code. Different arches do it differently, creating
diverging context-switch behavior. There are now 3 variants: fully
locked, unlocked but irqs-off, unlocked and irqs-on.
Nick has cleaned them up in
tested on x86, and all other arches should work as well, but if an
architecture has irqs-off assumptions in its switch_to() logic
it might break. (I havent found any but there may such assumptions.)
The ia64_switch_to() code includes a section that can change a pinned
MMU mapping (when the
* Luck, Tony [EMAIL PROTECTED] wrote:
tested on x86, and all other arches should work as well, but if an
architecture has irqs-off assumptions in its switch_to() logic
it might break. (I havent found any but there may such assumptions.)
The ia64_switch_to() code includes a section that
40 matches
Mail list logo
