[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <51F999DE.7080200@redhat.com>
Date: Wed, 31 Jul 2013 19:12:30 -0400
From: Rik van Riel <riel@...hat.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
CC: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
jmario@...hat.com, Peter Anvin <hpa@...or.com>, dzickus@...hat.com,
Ingo Molnar <mingo@...hat.com>
Subject: Re: [PATCH] sched,x86: optimize switch_mm for multi-threaded workloads
On 07/31/2013 06:46 PM, Linus Torvalds wrote:
>
> On Jul 31, 2013 3:39 PM, "Rik van Riel" <riel@...hat.com
> <mailto:riel@...hat.com>> wrote:
> >
> > On 07/31/2013 06:21 PM, Linus Torvalds wrote:
> >>
> >> Ummm.. The race is to the testing of the bit, not setting. The testing
> >> of the bit is not valid before we have set the tlb state, AFAIK.
> >
> >
> > I believe the bit is cleared and set by the current CPU.
>
> Yes, but we need to be careful with interrupts.
>
> > Interrupts are blocked inside switch_mm, so I think we
> > are safe.
>
> Are they? I thought we removed all that.
context_switch() shows that the runqueue lock (which is an irq
lock) is released, and irqs re-enabled, by the next task, after
switch_to(), in finish_lock_switch(), called from finish_task_switch()
> Note that switch_mm gets called for activate_mm too, or something.
Good catch, though it looks like activate_mm is only called from
exec_mmap, with the new mm as its argument. While the new mm can
have pages in memory yet, it has never been run so there should
be nothing in the TLB yet for the new mm.
This is subtler than I thought, but it does appear to be safe.
--
All rights reversed
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists