Hi Aneesh,
On Mon, Oct 27, 2014 at 11:28:41PM +0530, Aneesh Kumar K.V wrote:
> VM_BUG_ON(address & ~HPAGE_PMD_MASK);
> if (pmd_trans_huge(*pmdp)) {
> pmd = pmdp_get_and_clear(vma->vm_mm, address, pmdp);
> } else {
The only problematic path that needs IPI is the
Andrea Arcangeli writes:
> Hello,
>
> On Mon, Oct 27, 2014 at 07:50:41AM +1100, Benjamin Herrenschmidt wrote:
>> On Fri, 2014-10-24 at 09:22 -0700, James Bottomley wrote:
>>
>> > Parisc does this. As soon as one CPU issues a TLB purge, it's broadcast
>> > to all the CPUs on the inter-CPU bus.
Andrea Arcangeli aarca...@redhat.com writes:
Hello,
On Mon, Oct 27, 2014 at 07:50:41AM +1100, Benjamin Herrenschmidt wrote:
On Fri, 2014-10-24 at 09:22 -0700, James Bottomley wrote:
Parisc does this. As soon as one CPU issues a TLB purge, it's broadcast
to all the CPUs on the inter-CPU
Hi Aneesh,
On Mon, Oct 27, 2014 at 11:28:41PM +0530, Aneesh Kumar K.V wrote:
VM_BUG_ON(address ~HPAGE_PMD_MASK);
if (pmd_trans_huge(*pmdp)) {
pmd = pmdp_get_and_clear(vma-vm_mm, address, pmdp);
} else {
The only problematic path that needs IPI is the below
Hello,
On Mon, Oct 27, 2014 at 07:50:41AM +1100, Benjamin Herrenschmidt wrote:
> On Fri, 2014-10-24 at 09:22 -0700, James Bottomley wrote:
>
> > Parisc does this. As soon as one CPU issues a TLB purge, it's broadcast
> > to all the CPUs on the inter-CPU bus. The next instruction isn't
> >
On Fri, 2014-10-24 at 09:22 -0700, James Bottomley wrote:
> Parisc does this. As soon as one CPU issues a TLB purge, it's broadcast
> to all the CPUs on the inter-CPU bus. The next instruction isn't
> executed until they respond.
>
> But this is only for our CPU TLB. There's no other external
On Fri, 2014-10-24 at 09:22 -0700, James Bottomley wrote:
Parisc does this. As soon as one CPU issues a TLB purge, it's broadcast
to all the CPUs on the inter-CPU bus. The next instruction isn't
executed until they respond.
But this is only for our CPU TLB. There's no other external
Hello,
On Mon, Oct 27, 2014 at 07:50:41AM +1100, Benjamin Herrenschmidt wrote:
On Fri, 2014-10-24 at 09:22 -0700, James Bottomley wrote:
Parisc does this. As soon as one CPU issues a TLB purge, it's broadcast
to all the CPUs on the inter-CPU bus. The next instruction isn't
executed
David Miller writes:
> Hey guys, was looking over the generic GUP while working on a sparc64
> issue and I noticed that you guys do speculative page gets, and after
> talking with Johannes Weiner (CC:'d) about this we don't see how it
> could be necessary.
>
> If interrupts are disabled during
David Miller da...@davemloft.net writes:
Hey guys, was looking over the generic GUP while working on a sparc64
issue and I noticed that you guys do speculative page gets, and after
talking with Johannes Weiner (CC:'d) about this we don't see how it
could be necessary.
If interrupts are
On Fri, 2014-10-24 at 10:40 +1100, Benjamin Herrenschmidt wrote:
> On Thu, 2014-10-23 at 18:40 -0400, David Miller wrote:
> > Hey guys, was looking over the generic GUP while working on a sparc64
> > issue and I noticed that you guys do speculative page gets, and after
> > talking with Johannes
On 24 October 2014 00:40, Benjamin Herrenschmidt
wrote:
> On Thu, 2014-10-23 at 18:40 -0400, David Miller wrote:
>> Hey guys, was looking over the generic GUP while working on a sparc64
>> issue and I noticed that you guys do speculative page gets, and after
>> talking with Johannes Weiner
On 24 October 2014 00:40, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
On Thu, 2014-10-23 at 18:40 -0400, David Miller wrote:
Hey guys, was looking over the generic GUP while working on a sparc64
issue and I noticed that you guys do speculative page gets, and after
talking with
On Fri, 2014-10-24 at 10:40 +1100, Benjamin Herrenschmidt wrote:
On Thu, 2014-10-23 at 18:40 -0400, David Miller wrote:
Hey guys, was looking over the generic GUP while working on a sparc64
issue and I noticed that you guys do speculative page gets, and after
talking with Johannes Weiner
From: Benjamin Herrenschmidt
Date: Fri, 24 Oct 2014 10:40:35 +1100
> Another option would be to make the generic code use something defined
> by the arch to decide whether to use speculative get or
> not. I like the idea of keeping the bulk of that code generic...
Me too. We could have inlines
On Thu, 2014-10-23 at 18:40 -0400, David Miller wrote:
> Hey guys, was looking over the generic GUP while working on a sparc64
> issue and I noticed that you guys do speculative page gets, and after
> talking with Johannes Weiner (CC:'d) about this we don't see how it
> could be necessary.
>
> If
Hey guys, was looking over the generic GUP while working on a sparc64
issue and I noticed that you guys do speculative page gets, and after
talking with Johannes Weiner (CC:'d) about this we don't see how it
could be necessary.
If interrupts are disabled during the page table scan (which they
Andrew Morton writes:
> On Fri, 17 Oct 2014 10:08:06 +0530 "Aneesh Kumar K.V"
> wrote:
>
>> Update generic gup implementation with powerpc specific details.
>> On powerpc at pmd level we can have hugepte, normal pmd pointer
>> or a pointer to the hugepage directory.
>>
>> ...
>>
>> ---
Andrew Morton a...@linux-foundation.org writes:
On Fri, 17 Oct 2014 10:08:06 +0530 Aneesh Kumar K.V
aneesh.ku...@linux.vnet.ibm.com wrote:
Update generic gup implementation with powerpc specific details.
On powerpc at pmd level we can have hugepte, normal pmd pointer
or a pointer to the
Hey guys, was looking over the generic GUP while working on a sparc64
issue and I noticed that you guys do speculative page gets, and after
talking with Johannes Weiner (CC:'d) about this we don't see how it
could be necessary.
If interrupts are disabled during the page table scan (which they
On Thu, 2014-10-23 at 18:40 -0400, David Miller wrote:
Hey guys, was looking over the generic GUP while working on a sparc64
issue and I noticed that you guys do speculative page gets, and after
talking with Johannes Weiner (CC:'d) about this we don't see how it
could be necessary.
If
From: Benjamin Herrenschmidt b...@kernel.crashing.org
Date: Fri, 24 Oct 2014 10:40:35 +1100
Another option would be to make the generic code use something defined
by the arch to decide whether to use speculative get or
not. I like the idea of keeping the bulk of that code generic...
Me too.
Andrew Morton writes:
> On Fri, 17 Oct 2014 10:08:06 +0530 "Aneesh Kumar K.V"
> wrote:
>
>> Update generic gup implementation with powerpc specific details.
>> On powerpc at pmd level we can have hugepte, normal pmd pointer
>> or a pointer to the hugepage directory.
>>
>> ...
>>
>> ---
On Fri, 17 Oct 2014 10:08:06 +0530 "Aneesh Kumar K.V"
wrote:
> Update generic gup implementation with powerpc specific details.
> On powerpc at pmd level we can have hugepte, normal pmd pointer
> or a pointer to the hugepage directory.
>
> ...
>
> --- a/arch/arm/include/asm/pgtable.h
> +++
On Fri, 17 Oct 2014 10:08:06 +0530 Aneesh Kumar K.V
aneesh.ku...@linux.vnet.ibm.com wrote:
Update generic gup implementation with powerpc specific details.
On powerpc at pmd level we can have hugepte, normal pmd pointer
or a pointer to the hugepage directory.
...
---
Andrew Morton a...@linux-foundation.org writes:
On Fri, 17 Oct 2014 10:08:06 +0530 Aneesh Kumar K.V
aneesh.ku...@linux.vnet.ibm.com wrote:
Update generic gup implementation with powerpc specific details.
On powerpc at pmd level we can have hugepte, normal pmd pointer
or a pointer to the
On Fri, Oct 17, 2014 at 10:08:06AM +0530, Aneesh Kumar K.V wrote:
> Update generic gup implementation with powerpc specific details.
> On powerpc at pmd level we can have hugepte, normal pmd pointer
> or a pointer to the hugepage directory.
>
> Signed-off-by: Aneesh Kumar K.V
> ---
> Changes
On Fri, Oct 17, 2014 at 10:08:06AM +0530, Aneesh Kumar K.V wrote:
Update generic gup implementation with powerpc specific details.
On powerpc at pmd level we can have hugepte, normal pmd pointer
or a pointer to the hugepage directory.
Signed-off-by: Aneesh Kumar K.V
28 matches
Mail list logo
