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,
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
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
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
* 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
* 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
>
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
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
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
* 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
> >
* Linus Torvalds torva...@linux-foundation.org wrote:
On Thu, Oct 25, 2012 at 8:57 PM, Rik van Riel r...@redhat.com 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,
On Thu, Oct 25, 2012 at 9:23 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Thu, Oct 25, 2012 at 8:57 PM, Rik van Riel r...@redhat.com 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
Michel Lespinasse wal...@google.com writes:
On Thu, Oct 25, 2012 at 9:23 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Thu, Oct 25, 2012 at 8:57 PM, Rik van Riel r...@redhat.com wrote:
That may not even be needed. Apparently Intel chips
automatically flush an entry from the
On 10/26/2012 08:48 AM, Andi Kleen wrote:
Michel Lespinasse wal...@google.com writes:
On Thu, Oct 25, 2012 at 9:23 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Thu, Oct 25, 2012 at 8:57 PM, Rik van Riel r...@redhat.com wrote:
That may not even be needed. Apparently Intel
On Fri, Oct 26, 2012 at 5:48 AM, Andi Kleen a...@firstfloor.org wrote:
Michel Lespinasse wal...@google.com writes:
On Thu, Oct 25, 2012 at 9:23 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Thu, Oct 25, 2012 at 8:57 PM, Rik van Riel r...@redhat.com wrote:
That may not even be
* Rik van Riel r...@redhat.com wrote:
On 10/26/2012 08:48 AM, Andi Kleen wrote:
Michel Lespinasse wal...@google.com writes:
On Thu, Oct 25, 2012 at 9:23 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Thu, Oct 25, 2012 at 8:57 PM, Rik van Riel r...@redhat.com wrote:
That may
* Ingo Molnar mi...@kernel.org 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
On Fri, Oct 26, 2012 at 5:34 AM, Michel Lespinasse wal...@google.com wrote:
On Thu, Oct 25, 2012 at 9:23 PM, Linus Torvalds
torva...@linux-foundation.org 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 10/26/2012 01:01 PM, Linus Torvalds wrote:
On Fri, Oct 26, 2012 at 5:34 AM, Michel Lespinasse wal...@google.com wrote:
On Thu, Oct 25, 2012 at 9:23 PM, Linus Torvalds torva...@linux-foundation.org
wrote:
Yes. It's not architected as far as I know, though. But I agree, it's
possible - even
On Fri, Oct 26, 2012 at 10:54 AM, Rik van Riel r...@redhat.com 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
On 10/26/2012 02:02 PM, Linus Torvalds wrote:
On Fri, Oct 26, 2012 at 10:54 AM, Rik van Riel r...@redhat.com 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
On Fri, Oct 26, 2012 at 11:14 AM, Rik van Riel r...@redhat.com 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.
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.
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.
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
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
From: Rik van Riel
If ptep_set_access_flags() is invoked to upgrade access permissions
on a PTE, there is no security or data integrity reason to do a
remote TLB flush.
Lazily letting another CPU incur a spurious page fault occasionally
is (much!) cheaper than aggressively flushing everybody
From: Rik van Riel r...@redhat.com
If ptep_set_access_flags() is invoked to upgrade access permissions
on a PTE, there is no security or data integrity reason to do a
remote TLB flush.
Lazily letting another CPU incur a spurious page fault occasionally
is (much!) cheaper than aggressively
On Thu, Oct 25, 2012 at 5:16 AM, Peter Zijlstra a.p.zijls...@chello.nl wrote:
From: Rik van Riel r...@redhat.com
@@ -306,11 +306,26 @@ int ptep_set_access_flags(struct vm_area
pte_t entry, int dirty)
{
int changed = !pte_same(*ptep, entry);
+ /*
+
On 10/25/2012 04:17 PM, Linus Torvalds wrote:
On Thu, Oct 25, 2012 at 5:16 AM, Peter Zijlstra a.p.zijls...@chello.nl wrote:
From: Rik van Riel r...@redhat.com
@@ -306,11 +306,26 @@ int ptep_set_access_flags(struct vm_area
pte_t entry, int dirty)
{
int
On Thu, Oct 25, 2012 at 7:30 PM, Rik van Riel r...@redhat.com 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
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.
On Thu, Oct 25, 2012 at 8:57 PM, Rik van Riel r...@redhat.com 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.
36 matches
Mail list logo
