On Fri, Oct 26, 2012 at 11:14 AM, Rik van Riel wrote:
>
> I suspect the next context switch would flush out the TLB,
> making it a slowdown, not a lockup.
Common case, yes. But the page fault might happen in kernel space (due
to a "put_user()" call, say), and with CONFIG_PREEMPT=n.
Sure, put_use
On 10/26/2012 02:02 PM, Linus Torvalds wrote:
On Fri, Oct 26, 2012 at 10:54 AM, Rik van Riel wrote:
Would tlb_fix_spurious_fault take care of that on those
architectures?
.. assuming that they implement it as a real TLB flush, yes.
But maybe the architecture never noticed that it happened t
On Fri, Oct 26, 2012 at 10:54 AM, Rik van Riel wrote:
>
> Would tlb_fix_spurious_fault take care of that on those
> architectures?
.. assuming that they implement it as a real TLB flush, yes.
But maybe the architecture never noticed that it happened to depend on
the fact that we do a cross-CPU i
On 10/26/2012 01:01 PM, Linus Torvalds wrote:
On Fri, Oct 26, 2012 at 5:34 AM, Michel Lespinasse wrote:
On Thu, Oct 25, 2012 at 9:23 PM, Linus Torvalds
wrote:
Yes. It's not architected as far as I know, though. But I agree, it's
possible - even likely - we could avoid TLB flushing entirely
On Fri, Oct 26, 2012 at 5:34 AM, Michel Lespinasse wrote:
> On Thu, Oct 25, 2012 at 9:23 PM, Linus Torvalds
> wrote:
>>
>> Yes. It's not architected as far as I know, though. But I agree, it's
>> possible - even likely - we could avoid TLB flushing entirely on x86.
>
> Actually, it is architecte
* Ingo Molnar wrote:
> [...]
>
> Rik, mind sending an updated patch that addresses Linus's
> concerns, or should I code it up if you are busy?
>
> We can also certainly try the second patch, but I'd do it at
> the end of the series, to put some tree distance between the
> two patches, to no
* Rik van Riel wrote:
> On 10/26/2012 08:48 AM, Andi Kleen wrote:
> >Michel Lespinasse writes:
> >
> >>On Thu, Oct 25, 2012 at 9:23 PM, Linus Torvalds
> >> wrote:
> >>>On Thu, Oct 25, 2012 at 8:57 PM, Rik van Riel wrote:
>
> That may not even be needed. Apparently Intel chips
> a
On Fri, Oct 26, 2012 at 5:48 AM, Andi Kleen wrote:
> Michel Lespinasse writes:
>
>> On Thu, Oct 25, 2012 at 9:23 PM, Linus Torvalds
>> wrote:
>>> On Thu, Oct 25, 2012 at 8:57 PM, Rik van Riel wrote:
That may not even be needed. Apparently Intel chips
automatically flush an entry
On 10/26/2012 08:48 AM, Andi Kleen wrote:
Michel Lespinasse writes:
On Thu, Oct 25, 2012 at 9:23 PM, Linus Torvalds
wrote:
On Thu, Oct 25, 2012 at 8:57 PM, Rik van Riel wrote:
That may not even be needed. Apparently Intel chips
automatically flush an entry from the TLB when it
causes a p
Michel Lespinasse writes:
> On Thu, Oct 25, 2012 at 9:23 PM, Linus Torvalds
> wrote:
>> On Thu, Oct 25, 2012 at 8:57 PM, Rik van Riel wrote:
>>>
>>> That may not even be needed. Apparently Intel chips
>>> automatically flush an entry from the TLB when it
>>> causes a page fault. I assume AMD
On Thu, Oct 25, 2012 at 9:23 PM, Linus Torvalds
wrote:
> On Thu, Oct 25, 2012 at 8:57 PM, Rik van Riel wrote:
>>
>> That may not even be needed. Apparently Intel chips
>> automatically flush an entry from the TLB when it
>> causes a page fault. I assume AMD chips do the same,
>> because flush_t
* Linus Torvalds wrote:
> On Thu, Oct 25, 2012 at 8:57 PM, Rik van Riel wrote:
> >
> > That may not even be needed. Apparently Intel chips
> > automatically flush an entry from the TLB when it causes a
> > page fault. I assume AMD chips do the same, because
> > flush_tlb_fix_spurious_fault
On Thu, Oct 25, 2012 at 8:57 PM, Rik van Riel wrote:
>
> That may not even be needed. Apparently Intel chips
> automatically flush an entry from the TLB when it
> causes a page fault. I assume AMD chips do the same,
> because flush_tlb_fix_spurious_fault evaluates to
> nothing on x86.
Yes. It's
On 10/25/2012 10:56 PM, Linus Torvalds wrote:
Guess what? If you want to optimize the function to not do remote TLB
flushes, then just do that! None of the garbage. Just change the
flush_tlb_page(vma, address);
line to
__flush_tlb_one(address);
That may not even be needed. Appare
On Thu, Oct 25, 2012 at 7:30 PM, Rik van Riel wrote:
>>
>> LOOK at the code, for chrissake. Just look at it. And if you don't see
>> why the above is stupid and retarded, you damn well shouldn't be
>> touching VM code.
>
> I agree it is pretty ugly. However, the above patch
> did get rid of a gig
On 10/25/2012 04:17 PM, Linus Torvalds wrote:
On Thu, Oct 25, 2012 at 5:16 AM, Peter Zijlstra wrote:
From: Rik van Riel
@@ -306,11 +306,26 @@ int ptep_set_access_flags(struct vm_area
pte_t entry, int dirty)
{
int changed = !pte_same(*ptep, entry);
+
On Thu, Oct 25, 2012 at 5:16 AM, Peter Zijlstra wrote:
> From: Rik van Riel
>
> @@ -306,11 +306,26 @@ int ptep_set_access_flags(struct vm_area
> pte_t entry, int dirty)
> {
> int changed = !pte_same(*ptep, entry);
> + /*
> +* If the page used to be
17 matches
Mail list logo