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 bee
> 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 curre
> 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 just
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 page-no
> 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
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
* 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_
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_l
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 local_i
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 suc
> 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 gra
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 t
* 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 arch/ia64
* 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 uncondition
> 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
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 s
* 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 secti
>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 st
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 sched-
20 matches
Mail list logo
