On Fri, Nov 07, 2014 at 04:50:04PM +, Catalin Marinas wrote:
> On Thu, Nov 06, 2014 at 09:29:54PM +, Linus Torvalds wrote:
> > That's fine. That makes sense. In fact, how about adding "granularity"
> > to the mmu_gather structure, and then doing:\
> >
> > - in __tlb_reset_range(),
On Fri, Nov 07, 2014 at 04:50:04PM +, Catalin Marinas wrote:
On Thu, Nov 06, 2014 at 09:29:54PM +, Linus Torvalds wrote:
That's fine. That makes sense. In fact, how about adding granularity
to the mmu_gather structure, and then doing:\
- in __tlb_reset_range(), setting it to
On Thu, Nov 06, 2014 at 09:29:54PM +, Linus Torvalds wrote:
> On Thu, Nov 6, 2014 at 10:38 AM, Catalin Marinas
> wrote:
> > On Thu, Nov 06, 2014 at 05:53:58PM +, Linus Torvalds wrote:
> >
> > Sorry, I wasn't clear enough about the "increments" part. I agreed with
> > not using end = start
On Thu, Nov 06, 2014 at 09:29:54PM +, Linus Torvalds wrote:
On Thu, Nov 6, 2014 at 10:38 AM, Catalin Marinas
catalin.mari...@arm.com wrote:
On Thu, Nov 06, 2014 at 05:53:58PM +, Linus Torvalds wrote:
Sorry, I wasn't clear enough about the increments part. I agreed with
not using
On Thu, Nov 6, 2014 at 10:38 AM, Catalin Marinas
wrote:
> On Thu, Nov 06, 2014 at 05:53:58PM +, Linus Torvalds wrote:
>
> Sorry, I wasn't clear enough about the "increments" part. I agreed with
> not using end = start + PMD_SIZE/PAGE_SIZE from your previous email
> already.
Ahh, I
On Thu, Nov 06, 2014 at 05:53:58PM +, Linus Torvalds wrote:
> On Thu, Nov 6, 2014 at 5:57 AM, Catalin Marinas
> wrote:
> >
> > Anyway, even without special "leaf" operations, it would be useful to
> > make the distinction between unmap_vmas() and free_pgtables() with
> > regards to the
On Thu, Nov 6, 2014 at 5:57 AM, Catalin Marinas wrote:
>
> Anyway, even without special "leaf" operations, it would be useful to
> make the distinction between unmap_vmas() and free_pgtables() with
> regards to the ranges tracked by mmu_gather. For the former, tlb_flush()
> needs to flush the
On Tue, Nov 04, 2014 at 04:08:27PM +, Linus Torvalds wrote:
> On Tue, Nov 4, 2014 at 6:29 AM, Catalin Marinas
> wrote:
> >
> > This would work on arm64 but is the PAGE_SIZE range enough for all
> > architectures even when we flush a huge page or a pmd/pud table entry?
>
> It pretty much had
On Thu, Nov 6, 2014 at 5:57 AM, Catalin Marinas catalin.mari...@arm.com wrote:
Anyway, even without special leaf operations, it would be useful to
make the distinction between unmap_vmas() and free_pgtables() with
regards to the ranges tracked by mmu_gather. For the former, tlb_flush()
needs
On Thu, Nov 06, 2014 at 05:53:58PM +, Linus Torvalds wrote:
On Thu, Nov 6, 2014 at 5:57 AM, Catalin Marinas catalin.mari...@arm.com
wrote:
Anyway, even without special leaf operations, it would be useful to
make the distinction between unmap_vmas() and free_pgtables() with
regards
On Thu, Nov 6, 2014 at 10:38 AM, Catalin Marinas
catalin.mari...@arm.com wrote:
On Thu, Nov 06, 2014 at 05:53:58PM +, Linus Torvalds wrote:
Sorry, I wasn't clear enough about the increments part. I agreed with
not using end = start + PMD_SIZE/PAGE_SIZE from your previous email
already.
On Tue, Nov 04, 2014 at 04:08:27PM +, Linus Torvalds wrote:
On Tue, Nov 4, 2014 at 6:29 AM, Catalin Marinas catalin.mari...@arm.com
wrote:
This would work on arm64 but is the PAGE_SIZE range enough for all
architectures even when we flush a huge page or a pmd/pud table entry?
It
On Tue, Nov 4, 2014 at 6:29 AM, Catalin Marinas wrote:
>
> This would work on arm64 but is the PAGE_SIZE range enough for all
> architectures even when we flush a huge page or a pmd/pud table entry?
It pretty much had *better* be.
For things like page tables caches (ie caching addresses
(catching up with email after holiday)
On Wed, Oct 29, 2014 at 07:47:39PM +, Will Deacon wrote:
> mmu_gather: move minimal range calculations into generic code
>
> On architectures with hardware broadcasting of TLB invalidation messages
> , it makes sense to reduce the range
(catching up with email after holiday)
On Wed, Oct 29, 2014 at 07:47:39PM +, Will Deacon wrote:
mmu_gather: move minimal range calculations into generic code
On architectures with hardware broadcasting of TLB invalidation messages
, it makes sense to reduce the range of
On Tue, Nov 4, 2014 at 6:29 AM, Catalin Marinas catalin.mari...@arm.com wrote:
This would work on arm64 but is the PAGE_SIZE range enough for all
architectures even when we flush a huge page or a pmd/pud table entry?
It pretty much had *better* be.
For things like page tables caches (ie
On Mon, Nov 3, 2014 at 9:56 AM, Will Deacon wrote:
>
> We use `tlb->end > 0' in the arm64 backend, so I think you're right. I'll
> take a look in the name of cleanup and this can wait until 3.19.
Ok, I'll just archive this thread for now, and expect a patch at some
future date. And as far as I'm
On Sat, Nov 01, 2014 at 05:01:30PM +, Linus Torvalds wrote:
> On Wed, Oct 29, 2014 at 2:27 PM, Benjamin Herrenschmidt
> wrote:
> >
> > TLB flushing is only me I think, I'll engage my brain after breakfast
> > and see if is all good
>
> Ping? Breakfast is either long over, of you're starting
On Sat, Nov 01, 2014 at 05:01:30PM +, Linus Torvalds wrote:
On Wed, Oct 29, 2014 at 2:27 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
TLB flushing is only me I think, I'll engage my brain after breakfast
and see if is all good
Ping? Breakfast is either long over, of
On Mon, Nov 3, 2014 at 9:56 AM, Will Deacon will.dea...@arm.com wrote:
We use `tlb-end 0' in the arm64 backend, so I think you're right. I'll
take a look in the name of cleanup and this can wait until 3.19.
Ok, I'll just archive this thread for now, and expect a patch at some
future date. And
On Sat, 2014-11-01 at 10:01 -0700, Linus Torvalds wrote:
> On Wed, Oct 29, 2014 at 2:27 PM, Benjamin Herrenschmidt
> wrote:
> >
> > TLB flushing is only me I think, I'll engage my brain after breakfast
> > and see if is all good
>
> Ping? Breakfast is either long over, of you're starting to look
On Wed, Oct 29, 2014 at 2:27 PM, Benjamin Herrenschmidt
wrote:
>
> TLB flushing is only me I think, I'll engage my brain after breakfast
> and see if is all good
Ping? Breakfast is either long over, of you're starting to look a bit
like Mr Creosote...
Anyway, Will, I assume this is not a
On Wed, Oct 29, 2014 at 2:27 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
TLB flushing is only me I think, I'll engage my brain after breakfast
and see if is all good
Ping? Breakfast is either long over, of you're starting to look a bit
like Mr Creosote...
Anyway, Will, I assume
On Sat, 2014-11-01 at 10:01 -0700, Linus Torvalds wrote:
On Wed, Oct 29, 2014 at 2:27 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
TLB flushing is only me I think, I'll engage my brain after breakfast
and see if is all good
Ping? Breakfast is either long over, of you're
On Wed, 2014-10-29 at 14:11 -0700, Linus Torvalds wrote:
> On Wed, Oct 29, 2014 at 12:47 PM, Will Deacon wrote:
> >
> > I've cooked up something (see below), but it unfortunately makes a couple
> > of minor changes to powerpc and microblaze to address redefinitions of
> > some of the gather
On Wed, Oct 29, 2014 at 12:47 PM, Will Deacon wrote:
>
> I've cooked up something (see below), but it unfortunately makes a couple
> of minor changes to powerpc and microblaze to address redefinitions of
> some of the gather callbacks (tlb{start,end}vma, __tlb_remove_tlb_entry).
>
> On the plus
On Tue, Oct 28, 2014 at 09:40:35PM +, Linus Torvalds wrote:
> On Tue, Oct 28, 2014 at 8:30 AM, Linus Torvalds
> wrote:
> > On Tue, Oct 28, 2014 at 4:44 AM, Will Deacon wrote:
> >>
> >> This patch fixes the problem by incrementing addr by the PAGE_SIZE
> >> before breaking out of the loop on
On Tue, Oct 28, 2014 at 09:40:35PM +, Linus Torvalds wrote:
On Tue, Oct 28, 2014 at 8:30 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Tue, Oct 28, 2014 at 4:44 AM, Will Deacon will.dea...@arm.com wrote:
This patch fixes the problem by incrementing addr by the PAGE_SIZE
On Wed, Oct 29, 2014 at 12:47 PM, Will Deacon will.dea...@arm.com wrote:
I've cooked up something (see below), but it unfortunately makes a couple
of minor changes to powerpc and microblaze to address redefinitions of
some of the gather callbacks (tlb{start,end}vma, __tlb_remove_tlb_entry).
On Wed, 2014-10-29 at 14:11 -0700, Linus Torvalds wrote:
On Wed, Oct 29, 2014 at 12:47 PM, Will Deacon will.dea...@arm.com wrote:
I've cooked up something (see below), but it unfortunately makes a couple
of minor changes to powerpc and microblaze to address redefinitions of
some of the
On Tue, Oct 28, 2014 at 8:30 AM, Linus Torvalds
wrote:
> On Tue, Oct 28, 2014 at 4:44 AM, Will Deacon wrote:
>>
>> This patch fixes the problem by incrementing addr by the PAGE_SIZE
>> before breaking out of the loop on batch failure.
>
> This patch seems harmless and right [..]
I've applied it
On Tue, Oct 28, 2014 at 2:16 PM, Benjamin Herrenschmidt
wrote:
>>
>> Can't you just do a full invalidate and a SW IPI for larger ranges?
>
> For us, this would be great except ... we can potentially have other
> agents with an MMU that only support snooping of the broadcasts...
Ugh. Oh well. I
On Tue, 2014-10-28 at 09:25 -0700, Linus Torvalds wrote:
> > Since we have hardware broadcasting of TLB invalidations on ARM, it is
> > in our interest to keep the number of outstanding operations as small as
> > possible, particularly on large systems where we don't get the targetted
> >
On Tue, Oct 28, 2014 at 10:07 AM, Will Deacon wrote:
>
> I don't think that's necessarily true, at least not on the systems I'm
> familiar with. A table walk can be comparatively expensive, particularly
> when virtualisation is involved and the depth of the host and guest page
> tables starts to
On Tue, Oct 28, 2014 at 04:25:35PM +, Linus Torvalds wrote:
> On Tue, Oct 28, 2014 at 9:07 AM, Will Deacon wrote:
> > I was certainly seeing this issue trigger regularly when running firefox,
> > but I'll need to dig and find out the differences in range size.
>
> I'm wondering whether that
On Tue, Oct 28, 2014 at 9:07 AM, Will Deacon wrote:
>
> Ok, that's useful, thanks. Out of curiosity, what *is* the current intention
> of __tlb_remove_tlb_entry, if start/end shouldn't be touched by
> architectures? Is it just for the PPC hash thing?
I think it's both the PPC hash, and for
Hi Linus,
On Tue, Oct 28, 2014 at 03:30:43PM +, Linus Torvalds wrote:
> On Tue, Oct 28, 2014 at 4:44 AM, Will Deacon wrote:
> > This patch fixes the problem by incrementing addr by the PAGE_SIZE
> > before breaking out of the loop on batch failure.
>
> This patch seems harmless and right,
On Tue, Oct 28, 2014 at 4:44 AM, Will Deacon wrote:
>
> This patch fixes the problem by incrementing addr by the PAGE_SIZE
> before breaking out of the loop on batch failure.
This patch seems harmless and right, unlike the other one.
I'd be ok with changing the *generic* code to do the "update
When unmapping a range of pages in zap_pte_range, the page being
unmapped is added to an mmu_gather_batch structure for asynchronous
freeing. If we run out of space in the batch structure before the range
has been completely unmapped, then we break out of the loop, force a
TLB flush and free the
When unmapping a range of pages in zap_pte_range, the page being
unmapped is added to an mmu_gather_batch structure for asynchronous
freeing. If we run out of space in the batch structure before the range
has been completely unmapped, then we break out of the loop, force a
TLB flush and free the
On Tue, Oct 28, 2014 at 4:44 AM, Will Deacon will.dea...@arm.com wrote:
This patch fixes the problem by incrementing addr by the PAGE_SIZE
before breaking out of the loop on batch failure.
This patch seems harmless and right, unlike the other one.
I'd be ok with changing the *generic* code to
Hi Linus,
On Tue, Oct 28, 2014 at 03:30:43PM +, Linus Torvalds wrote:
On Tue, Oct 28, 2014 at 4:44 AM, Will Deacon will.dea...@arm.com wrote:
This patch fixes the problem by incrementing addr by the PAGE_SIZE
before breaking out of the loop on batch failure.
This patch seems harmless
On Tue, Oct 28, 2014 at 9:07 AM, Will Deacon will.dea...@arm.com wrote:
Ok, that's useful, thanks. Out of curiosity, what *is* the current intention
of __tlb_remove_tlb_entry, if start/end shouldn't be touched by
architectures? Is it just for the PPC hash thing?
I think it's both the PPC
On Tue, Oct 28, 2014 at 04:25:35PM +, Linus Torvalds wrote:
On Tue, Oct 28, 2014 at 9:07 AM, Will Deacon will.dea...@arm.com wrote:
I was certainly seeing this issue trigger regularly when running firefox,
but I'll need to dig and find out the differences in range size.
I'm wondering
On Tue, Oct 28, 2014 at 10:07 AM, Will Deacon will.dea...@arm.com wrote:
I don't think that's necessarily true, at least not on the systems I'm
familiar with. A table walk can be comparatively expensive, particularly
when virtualisation is involved and the depth of the host and guest page
On Tue, 2014-10-28 at 09:25 -0700, Linus Torvalds wrote:
Since we have hardware broadcasting of TLB invalidations on ARM, it is
in our interest to keep the number of outstanding operations as small as
possible, particularly on large systems where we don't get the targetted
shootdown with
On Tue, Oct 28, 2014 at 2:16 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
Can't you just do a full invalidate and a SW IPI for larger ranges?
For us, this would be great except ... we can potentially have other
agents with an MMU that only support snooping of the broadcasts...
On Tue, Oct 28, 2014 at 8:30 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Tue, Oct 28, 2014 at 4:44 AM, Will Deacon will.dea...@arm.com wrote:
This patch fixes the problem by incrementing addr by the PAGE_SIZE
before breaking out of the loop on batch failure.
This patch seems
48 matches
Mail list logo
