On Fri, 2015-10-02 at 13:09 -0700, Nishanth Aravamudan wrote:
> 1) add a generic dma_get_page_shift implementation that just returns
> PAGE_SHIFT
So you chose to return the granularity of the iommu to the driver
rather than providing a way for the driver to request a specific
alignment for DMA
On Fri, 2015-10-02 at 14:04 -0700, Nishanth Aravamudan wrote:
> Right, I did start with your advice and tried that approach, but it
> turned out I was wrong about the actual issue at the time. The problem
> for NVMe isn't actually the starting address alignment (which it can
> handle not being
On Wed, 2015-08-19 at 23:37 +0200, Laurent Dufour wrote:
> On 03/08/2015 13:00, David Laight wrote:
From: Laurent Dufour
> > > Sent: 31 July 2015 10:30
> > > This patch fixes several endianness issues detected when running
> > > the HVSI
> > > driver in little endian mode.
> > >
> > > These
On Wed, 2015-08-19 at 23:37 +0200, Laurent Dufour wrote:
On 03/08/2015 13:00, David Laight wrote:
From: Laurent Dufour
Sent: 31 July 2015 10:30
This patch fixes several endianness issues detected when running
the HVSI
driver in little endian mode.
These issues are raised in
On Mon, 2015-08-17 at 11:53 +0200, Vlastimil Babka wrote:
> I meant why the kernel used for QEMU has also CMA enabled and used
> (for
> something else)? CMA is mostly used on mobile devices and they don't
> run
> QEMU?
I explained in a separeate reply but yes, we do use a CMA for KVM for
our
On Mon, 2015-08-17 at 19:11 +1000, Alexey Kardashevskiy wrote:
> On 08/17/2015 05:45 PM, Vlastimil Babka wrote:
> > On 08/05/2015 10:08 AM, Alexey Kardashevskiy wrote:
> > > This is about VFIO aka PCI passthrough used from QEMU.
> > > KVM is irrelevant here.
> > >
> > > QEMU is a machine
On Mon, 2015-08-17 at 11:53 +0200, Vlastimil Babka wrote:
I meant why the kernel used for QEMU has also CMA enabled and used
(for
something else)? CMA is mostly used on mobile devices and they don't
run
QEMU?
I explained in a separeate reply but yes, we do use a CMA for KVM for
our MMU
On Mon, 2015-08-17 at 19:11 +1000, Alexey Kardashevskiy wrote:
On 08/17/2015 05:45 PM, Vlastimil Babka wrote:
On 08/05/2015 10:08 AM, Alexey Kardashevskiy wrote:
This is about VFIO aka PCI passthrough used from QEMU.
KVM is irrelevant here.
QEMU is a machine emulator. It allocates
On Tue, 2015-08-04 at 20:08 +1000, Michael Ellerman wrote:
> On Tue, 2015-04-08 at 08:30:58 UTC, "Gautham R. Shenoy" wrote:
> > Section 3.7 of Version 1.2 of the Power8 Processor User's Manual
> > prescribes that updates to HID0 be preceded by a SYNC instruction and
> > followed by an ISYNC
On Tue, 2015-08-04 at 20:08 +1000, Michael Ellerman wrote:
On Tue, 2015-04-08 at 08:30:58 UTC, Gautham R. Shenoy wrote:
Section 3.7 of Version 1.2 of the Power8 Processor User's Manual
prescribes that updates to HID0 be preceded by a SYNC instruction and
followed by an ISYNC instruction
On Mon, 2015-07-20 at 14:39 +0100, Will Deacon wrote:
> On Fri, Jul 17, 2015 at 11:14:14PM +0100, Benjamin Herrenschmidt wrote:
> > On Fri, 2015-07-17 at 10:32 +0100, Will Deacon wrote:
> > > static inline void arch_spin_unlock(arch_spinlock_t *lock)
> > &g
On Mon, 2015-07-20 at 14:39 +0100, Will Deacon wrote:
On Fri, Jul 17, 2015 at 11:14:14PM +0100, Benjamin Herrenschmidt wrote:
On Fri, 2015-07-17 at 10:32 +0100, Will Deacon wrote:
static inline void arch_spin_unlock(arch_spinlock_t *lock)
{
- SYNC_IO;
- __asm__
On Fri, 2015-07-17 at 10:32 +0100, Will Deacon wrote:
> static inline void arch_spin_unlock(arch_spinlock_t *lock)
> {
> - SYNC_IO;
> - __asm__ __volatile__("# arch_spin_unlock\n\t"
> - PPC_RELEASE_BARRIER: : :"memory");
> + smp_mb();
>
On Fri, 2015-07-17 at 10:32 +0100, Will Deacon wrote:
static inline void arch_spin_unlock(arch_spinlock_t *lock)
{
- SYNC_IO;
- __asm__ __volatile__(# arch_spin_unlock\n\t
- PPC_RELEASE_BARRIER: : :memory);
+ smp_mb();
lock-slock =
On Thu, 2015-07-16 at 08:11 -0700, Paul E. McKenney wrote:
> > So isync in lock in architecturally incorrect, despite being what
> the
> > architecture recommends using, yay !
>
> Well, the architecture isn't expecting that crazies like myself would
> want to have an unlock-lock provide ordering
negative MAX_ERRNO have already been updated to
> use force_successful_syscall_return().
>
> I have also checked all the powerpc specific syscalls, and believe that
> none of them expect to return a non-error value between -MAX_ERRNO and
> -516. So this change should be safe ...
>
> Signed-off-by:
On Wed, 2015-07-15 at 17:37 +1000, Michael Ellerman wrote:
> To call do_syscall_trace_enter() we need pt_regs in r3, but we don't need
> to recalculate it based on r1, it's already in r9.
>
> Signed-off-by: Michael Ellerman
Is there any performance difference ?
I find the addi a bit more
also checked all the powerpc specific syscalls, and believe that
none of them expect to return a non-error value between -MAX_ERRNO and
-516. So this change should be safe ...
Signed-off-by: Michael Ellerman m...@ellerman.id.au
Acked-by: Benjamin Herrenschmidt b...@kernel.crashing.org
On Wed, 2015-07-15 at 17:37 +1000, Michael Ellerman wrote:
To call do_syscall_trace_enter() we need pt_regs in r3, but we don't need
to recalculate it based on r1, it's already in r9.
Signed-off-by: Michael Ellerman m...@ellerman.id.au
Is there any performance difference ?
I find the addi a
On Thu, 2015-07-16 at 08:11 -0700, Paul E. McKenney wrote:
So isync in lock in architecturally incorrect, despite being what
the
architecture recommends using, yay !
Well, the architecture isn't expecting that crazies like myself would
want to have an unlock-lock provide ordering to some
On Thu, 2015-07-16 at 15:03 +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2015-07-16 at 12:00 +1000, Michael Ellerman wrote:
> > That would fix the problem with smp_mb__after_unlock_lock(), but not
> > the original worry we had about loads happening before the SC in lock.
>
On Thu, 2015-07-16 at 12:00 +1000, Michael Ellerman wrote:
> That would fix the problem with smp_mb__after_unlock_lock(), but not
> the original worry we had about loads happening before the SC in lock.
However I think isync fixes *that* :-) The problem with isync is as you
said, it's not a
On Thu, 2015-07-16 at 12:00 +1000, Michael Ellerman wrote:
That would fix the problem with smp_mb__after_unlock_lock(), but not
the original worry we had about loads happening before the SC in lock.
However I think isync fixes *that* :-) The problem with isync is as you
said, it's not a
On Thu, 2015-07-16 at 15:03 +1000, Benjamin Herrenschmidt wrote:
On Thu, 2015-07-16 at 12:00 +1000, Michael Ellerman wrote:
That would fix the problem with smp_mb__after_unlock_lock(), but not
the original worry we had about loads happening before the SC in lock.
However I think isync
On Tue, 2015-07-14 at 17:58 +1000, Finn Thain wrote:
> Make use of arch_nvram_ops in device drivers so that the nvram_* function
> exports can be removed.
>
> Since they are no longer global symbols, rename the PPC32 nvram_*
> functions appropriately.
>
> Add the missing CONFIG_NVRAM test to
On Tue, 2015-07-14 at 17:58 +1000, Finn Thain wrote:
Make use of arch_nvram_ops in device drivers so that the nvram_* function
exports can be removed.
Since they are no longer global symbols, rename the PPC32 nvram_*
functions appropriately.
Add the missing CONFIG_NVRAM test to imsttfb
On Tue, 2015-07-14 at 00:15 +0200, Peter Zijlstra wrote:
> > This is instead the sequence that is of concern:
> >
> > store a
> > unlock M
> > lock N
> > load b
>
> So its late and that table didn't parse, but that should be ordered too.
> The load of b should not be able to
On Mon, 2015-07-13 at 17:54 +0200, Peter Zijlstra wrote:
> That said, I don't think this could even happen on PPC because we have
> load_acquire and store_release, this means that:
>
> *A = a
> lwsync
> store_release M
> load_acquire N
> lwsync
> *B = b
>
>
he barrier and instead requires architectures to
> provide full barrier semantics for an UNLOCK + LOCK sequence.
>
> Cc: Benjamin Herrenschmidt
> Cc: Paul McKenney
> Cc: Peter Zijlstra
> Signed-off-by: Will Deacon
> ---
>
> This didn't go anywhere last time I po
for an UNLOCK + LOCK sequence.
Cc: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Paul McKenney paul...@linux.vnet.ibm.com
Cc: Peter Zijlstra pet...@infradead.org
Signed-off-by: Will Deacon will.dea...@arm.com
---
This didn't go anywhere last time I posted it, but here it is again.
I'd
On Mon, 2015-07-13 at 17:54 +0200, Peter Zijlstra wrote:
That said, I don't think this could even happen on PPC because we have
load_acquire and store_release, this means that:
*A = a
lwsync
store_release M
load_acquire N
lwsync
*B = b
And since
On Tue, 2015-07-14 at 00:15 +0200, Peter Zijlstra wrote:
This is instead the sequence that is of concern:
store a
unlock M
lock N
load b
So its late and that table didn't parse, but that should be ordered too.
The load of b should not be able to escape the lock N.
TOMIC64_OP(or, or)
> +ATOMIC64_OP(xor, xor)
As long as you are ok that they are non-ordered atomics (no barrier in
them), then
Acked-by: Benjamin Herrenschmidt
> #undef ATOMIC64_OPS
> #undef ATOMIC64_OP_RETURN
>
>
> --
> To unsubscribe from this list: send the line &
atomics (no barrier in
them), then
Acked-by: Benjamin Herrenschmidt b...@kernel.crashing.org
#undef ATOMIC64_OPS
#undef ATOMIC64_OP_RETURN
--
To unsubscribe from this list: send the line unsubscribe
linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info
_mb() users really are about SMP ordering, not IO
> ordering, change them all to be consistent.
>
> Cc: Tony Luck
For powerpc:
Acked-by: Benjamin Herrenschmidt
> Cc: Heiko Carstens
> Suggested-by: Linus Torvalds
> Signed-off-by: Peter Zijlstra (Intel)
> ---
> arch/ia
On Thu, 2015-07-02 at 20:49 +0200, Luis R. Rodriguez wrote:
> > The question then is what is "the right thing". In the powerpc case,
> > we'll have a non-garded mapping, which means we also get no ordering
> > between load and stores.
>
> I don't follow, you *ordering* between load and stores for
On Thu, 2015-07-02 at 20:49 +0200, Luis R. Rodriguez wrote:
The question then is what is the right thing. In the powerpc case,
we'll have a non-garded mapping, which means we also get no ordering
between load and stores.
I don't follow, you *ordering* between load and stores for WC? We
SMP ordering, not IO
ordering, change them all to be consistent.
Cc: Tony Luck tony.l...@intel.com
For powerpc:
Acked-by: Benjamin Herrenschmidt b...@kernel.crashing.org
Cc: Heiko Carstens heiko.carst...@de.ibm.com
Suggested-by: Linus Torvalds torva...@linux-foundation.org
Signed-off
On Fri, 2015-06-26 at 15:41 -0700, Luis R. Rodriguez wrote:
> > It wasn't nullified for the main user at the time, the fb. And I
> > mentioned an IB adapter or two for which the code had been hand
> tuned.
>
> This still means there could be some affected drivers when used on
> powerpc, no?
On Fri, 2015-06-26 at 21:31 +0200, Luis R. Rodriguez wrote:
> > Yeah either, we need to fix our relaxed implementation (patch
> > welcome :-)
>
> Yikes, so although powerpc has useful heuristics to automatically
> enable WC the default write ops have been nullifying its effects?
The heuristic is
would use this to
> eliminate a wasteful attempt to use write combining on those
> architectures where it didn't work.
>
> Casey
>
>
> From: Benjamin Herrenschmidt [b...@kernel.crashing.org]
> Sent: Thursday, June 25, 2015 7:02 PM
> To:
On Fri, 2015-06-26 at 15:41 -0700, Luis R. Rodriguez wrote:
It wasn't nullified for the main user at the time, the fb. And I
mentioned an IB adapter or two for which the code had been hand
tuned.
This still means there could be some affected drivers when used on
powerpc, no?
Yes. In
.
Casey
From: Benjamin Herrenschmidt [b...@kernel.crashing.org]
Sent: Thursday, June 25, 2015 7:02 PM
To: Casey Leedom
Cc: Arnd Bergmann; Luis R. Rodriguez; Michael S. Tsirkin; Bjorn Helgaas;
Toshi Kani; Andy Lutomirski; Juergen Gross; Tomi
On Fri, 2015-06-26 at 21:31 +0200, Luis R. Rodriguez wrote:
Yeah either, we need to fix our relaxed implementation (patch
welcome :-)
Yikes, so although powerpc has useful heuristics to automatically
enable WC the default write ops have been nullifying its effects?
The heuristic is for
On Thu, 2015-06-25 at 21:40 +, Casey Leedom wrote:
>
> Ah, thanks. I see now that the __raw_*() APIs don't do any of the
> Endian Swizzling. Unfortunately the *_relaxed() APIs on PowerPC
> are just defined as the normal *() routines. From
> arch/powerpc/include/asm/io.h:
>
> /*
>
On Wed, 2015-06-24 at 18:22 -0700, Luis R. Rodriguez wrote:
> Although I had test compiled this before just to be safe I went ahead and
> successfully test-compiled this set with allmodconfig, specially since I've
> now
> removed the exports for the devres routines. Please let me know if these
On Thu, 2015-06-25 at 21:40 +, Casey Leedom wrote:
> Hhmmm, so what do PowerPC Drivers do when they want to take
> advantage of Write Combining? Do their own Endian Swizzling
> with the __raw_*() APIs?
Yeah either, we need to fix our relaxed implementation (patch
welcome :-)
Cheers,
Ben.
On Thu, 2015-06-25 at 21:40 +, Casey Leedom wrote:
Hhmmm, so what do PowerPC Drivers do when they want to take
advantage of Write Combining? Do their own Endian Swizzling
with the __raw_*() APIs?
Yeah either, we need to fix our relaxed implementation (patch
welcome :-)
Cheers,
Ben.
--
On Thu, 2015-06-25 at 21:40 +, Casey Leedom wrote:
Ah, thanks. I see now that the __raw_*() APIs don't do any of the
Endian Swizzling. Unfortunately the *_relaxed() APIs on PowerPC
are just defined as the normal *() routines. From
arch/powerpc/include/asm/io.h:
/*
* We
On Wed, 2015-06-24 at 18:22 -0700, Luis R. Rodriguez wrote:
Although I had test compiled this before just to be safe I went ahead and
successfully test-compiled this set with allmodconfig, specially since I've
now
removed the exports for the devres routines. Please let me know if these
On Wed, 2015-06-24 at 17:58 -0700, Luis R. Rodriguez wrote:
> On Wed, Jun 24, 2015 at 5:52 PM, Benjamin Herrenschmidt
> wrote:
> > On Thu, 2015-06-25 at 02:08 +0200, Luis R. Rodriguez wrote:
> >>
> >> OK thanks I'll proceed with these patches then.
&g
On Wed, 2015-06-24 at 18:38 +0200, Luis R. Rodriguez wrote:
> On Wed, Jun 24, 2015 at 08:42:23AM +1000, Benjamin Herrenschmidt wrote:
> > On Fri, 2015-06-19 at 15:08 -0700, Luis R. Rodriguez wrote:
> > > From: "Luis R. Rodriguez"
> > >
> > >
On Thu, 2015-06-25 at 02:08 +0200, Luis R. Rodriguez wrote:
>
> OK thanks I'll proceed with these patches then.
>
> > As for user mappings,
>
> Which APIs were you considering in this regard BTW?
mmap of the generic /sys/bus/pci/.../resource*
> > maybe the right thing to do is to let us do
On Wed, 2015-06-24 at 15:50 +0200, Rafael J. Wysocki wrote:
> 4.2 material I suppose?
And stable. Without this, if you configure without TICK_ONESHOT, the
machine will hang.
Cheers,
Ben.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
On Wed, 2015-06-24 at 15:29 -0700, Luis R. Rodriguez wrote:
> Nope but at least what made me squint at this being a possible
> "feature" was that in practice when reviewing all of the kernels
> pending device drivers using MTRR (potential write-combine candidates)
> I encountered a slew of them
On Wed, 2015-06-24 at 17:58 -0700, Luis R. Rodriguez wrote:
On Wed, Jun 24, 2015 at 5:52 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
On Thu, 2015-06-25 at 02:08 +0200, Luis R. Rodriguez wrote:
OK thanks I'll proceed with these patches then.
As for user mappings
On Wed, 2015-06-24 at 15:29 -0700, Luis R. Rodriguez wrote:
Nope but at least what made me squint at this being a possible
feature was that in practice when reviewing all of the kernels
pending device drivers using MTRR (potential write-combine candidates)
I encountered a slew of them which
On Wed, 2015-06-24 at 15:50 +0200, Rafael J. Wysocki wrote:
4.2 material I suppose?
And stable. Without this, if you configure without TICK_ONESHOT, the
machine will hang.
Cheers,
Ben.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to
On Wed, 2015-06-24 at 18:38 +0200, Luis R. Rodriguez wrote:
On Wed, Jun 24, 2015 at 08:42:23AM +1000, Benjamin Herrenschmidt wrote:
On Fri, 2015-06-19 at 15:08 -0700, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
PCI BARs tell us whether prefetching is safe
On Thu, 2015-06-25 at 02:08 +0200, Luis R. Rodriguez wrote:
OK thanks I'll proceed with these patches then.
As for user mappings,
Which APIs were you considering in this regard BTW?
mmap of the generic /sys/bus/pci/.../resource*
maybe the right thing to do is to let us do what we do
On Tue, 2015-06-23 at 18:02 -0500, Bjorn Helgaas wrote:
> On Tue, Jun 23, 2015 at 5:46 PM, Benjamin Herrenschmidt
> wrote:
> > On Tue, 2015-06-02 at 15:55 +0100, Lorenzo Pieralisi wrote:
> >> While at it, do you think it is reasonable to also claim the bridge
&g
On Mon, 2014-09-29 at 12:17 -0600, Bjorn Helgaas wrote:
> This seems like more than necessary, but I don't know all the history.
> In particular, I don't know why PCI_PROBE_ONLY should make a
> difference to things like claiming resources.
It shouldn't ... we created that option on ppc originally
On Tue, 2015-06-02 at 15:55 +0100, Lorenzo Pieralisi wrote:
> While at it, do you think it is reasonable to also claim the bridge
> windows (resources) in the respective pci_read_bridge_* calls ?
No, don't claim in read. There's a clear distinction between gathering
resources and claiming them,
On Fri, 2015-06-19 at 15:08 -0700, Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez"
>
> PCI BARs tell us whether prefetching is safe, but they don't say anything
> about write combining (WC). WC changes ordering rules and allows writes to
> be collapsed, so it's not safe in general to use
On Sun, 2014-09-28 at 15:53 -0500, suravee.suthikulpa...@amd.com wrote:
> From: Suravee Suthikulpanit
>
> When specify PCI_PROBE_ONLY, the resource parent does not get assigned.
> Therefore, pci_enable_resources() return error saying that
> "BAR x not claimed".
>
> Note: This same logic is also
On Sun, 2014-09-28 at 15:53 -0500, suravee.suthikulpa...@amd.com wrote:
From: Suravee Suthikulpanit suravee.suthikulpa...@amd.com
When specify PCI_PROBE_ONLY, the resource parent does not get assigned.
Therefore, pci_enable_resources() return error saying that
BAR x not claimed.
Note:
On Mon, 2014-09-29 at 12:17 -0600, Bjorn Helgaas wrote:
This seems like more than necessary, but I don't know all the history.
In particular, I don't know why PCI_PROBE_ONLY should make a
difference to things like claiming resources.
It shouldn't ... we created that option on ppc originally to
On Tue, 2015-06-02 at 15:55 +0100, Lorenzo Pieralisi wrote:
While at it, do you think it is reasonable to also claim the bridge
windows (resources) in the respective pci_read_bridge_* calls ?
No, don't claim in read. There's a clear distinction between gathering
resources and claiming them, and
On Tue, 2015-06-23 at 18:02 -0500, Bjorn Helgaas wrote:
On Tue, Jun 23, 2015 at 5:46 PM, Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
On Tue, 2015-06-02 at 15:55 +0100, Lorenzo Pieralisi wrote:
While at it, do you think it is reasonable to also claim the bridge
windows (resources
On Fri, 2015-06-19 at 15:08 -0700, Luis R. Rodriguez wrote:
From: Luis R. Rodriguez mcg...@suse.com
PCI BARs tell us whether prefetching is safe, but they don't say anything
about write combining (WC). WC changes ordering rules and allows writes to
be collapsed, so it's not safe in general
On Fri, 2015-06-05 at 13:23 -0700, Guenter Roeck wrote:
> On 06/05/2015 01:08 PM, Benjamin Herrenschmidt wrote:
> > On Fri, 2015-06-05 at 11:05 -0700, Guenter Roeck wrote:
> >> A 64 bit divide causes build failures with 32 bit builds, such as
> >>
> >> ERROR:
On Fri, 2015-06-05 at 13:23 -0700, Guenter Roeck wrote:
On 06/05/2015 01:08 PM, Benjamin Herrenschmidt wrote:
On Fri, 2015-06-05 at 11:05 -0700, Guenter Roeck wrote:
A 64 bit divide causes build failures with 32 bit builds, such as
ERROR: __divdi3 [drivers/video/fbdev/aty/radeonfb.ko
On Fri, 2015-06-05 at 11:05 -0700, Guenter Roeck wrote:
> A 64 bit divide causes build failures with 32 bit builds, such as
>
> ERROR: "__divdi3" [drivers/video/fbdev/aty/radeonfb.ko] undefined!
>
> or
>
> drivers/built-in.o: In function `radeon_probe_pll_params':
>
On Fri, 2015-06-05 at 11:05 -0700, Guenter Roeck wrote:
A 64 bit divide causes build failures with 32 bit builds, such as
ERROR: __divdi3 [drivers/video/fbdev/aty/radeonfb.ko] undefined!
or
drivers/built-in.o: In function `radeon_probe_pll_params':
radeon_base.c:(.text+0x16608b):
On Sat, 2015-05-30 at 11:31 +0530, Vaidyanathan Srinivasan wrote:
> In shared lpar case, spinning in guest context may potentially take
> away cycles from other lpars waiting to run on the same physical cpu.
>
> So the policy in shared lpar case is to let PowerVM hypervisor know
> immediately
On Sat, 2015-05-30 at 11:31 +0530, Vaidyanathan Srinivasan wrote:
In shared lpar case, spinning in guest context may potentially take
away cycles from other lpars waiting to run on the same physical cpu.
So the policy in shared lpar case is to let PowerVM hypervisor know
immediately that the
On Thu, 2015-05-21 at 14:23 -0700, Andrew Morton wrote:
> On Tue, 19 May 2015 22:15:37 -0700 Joe Perches wrote:
>
> > Jens' email address bounces, so move his name and entry to CREDITS.
> >
> > --- a/CREDITS
> > +++ b/CREDITS
> > @@ -2740,6 +2740,10 @@ S: C/ Mieses 20, 9-B
> > S: Valladolid
On Thu, 2015-05-21 at 14:23 -0700, Andrew Morton wrote:
On Tue, 19 May 2015 22:15:37 -0700 Joe Perches j...@perches.com wrote:
Jens' email address bounces, so move his name and entry to CREDITS.
--- a/CREDITS
+++ b/CREDITS
@@ -2740,6 +2740,10 @@ S: C/ Mieses 20, 9-B
S: Valladolid
On Thu, 2015-05-14 at 09:39 +0200, Vlastimil Babka wrote:
> On 05/14/2015 01:38 AM, Benjamin Herrenschmidt wrote:
> > On Wed, 2015-05-13 at 16:10 +0200, Vlastimil Babka wrote:
> >> Sorry for reviving oldish thread...
> >
> > Well, that's actually appreciated since t
On Thu, 2015-05-14 at 09:39 +0200, Vlastimil Babka wrote:
On 05/14/2015 01:38 AM, Benjamin Herrenschmidt wrote:
On Wed, 2015-05-13 at 16:10 +0200, Vlastimil Babka wrote:
Sorry for reviving oldish thread...
Well, that's actually appreciated since this is constructive discussion
de 0 CAPI dev ] [ node 1 mem] [ node 1 CAPI dev] ...
> On 04/28/2015 01:54 AM, Benjamin Herrenschmidt wrote:
> > On Mon, 2015-04-27 at 11:48 -0500, Christoph Lameter wrote:
> >> On Mon, 27 Apr 2015, Rik van Riel wrote:
> >>
> >>> Why would we want to avoi
] [ node 1 mem] [ node 1 CAPI dev] ...
On 04/28/2015 01:54 AM, Benjamin Herrenschmidt wrote:
On Mon, 2015-04-27 at 11:48 -0500, Christoph Lameter wrote:
On Mon, 27 Apr 2015, Rik van Riel wrote:
Why would we want to avoid the sane approach that makes this thing
work with the fewest required
On Tue, 2015-05-12 at 17:12 +0400, Ivan Mikhaylov wrote:
> Fix in send of emac regs dump to ethtool which
> causing wrong data interpretation on ethtool
> layer for MII and EMAC.
Please provide a better explanation. You removed the difference
in register space size between EMAC and EMAC4, why ?
On Tue, 2015-05-12 at 17:12 +0400, Ivan Mikhaylov wrote:
Fix in send of emac regs dump to ethtool which
causing wrong data interpretation on ethtool
layer for MII and EMAC.
Please provide a better explanation. You removed the difference
in register space size between EMAC and EMAC4, why ? You
On Wed, 2015-05-06 at 19:50 +0200, David Hildenbrand wrote:
> enable_kernel_altivec() has to be called with disabled preemption.
> Let's make this explicit, to prepare for pagefault_disable() not
> touching preemption anymore.
>
> Signed-off-by: David Hildenbrand
Acked-by: Benjami
-by: Benjamin Herrenschmidt b...@kernel.crashing.org
---
arch/powerpc/lib/vmx-helper.c | 11 ++-
drivers/crypto/vmx/aes.c | 8 +++-
drivers/crypto/vmx/aes_cbc.c | 6 ++
drivers/crypto/vmx/ghash.c| 8
4 files changed, 27 insertions(+), 6 deletions(-)
diff --git
On Thu, 2015-04-30 at 19:33 +1000, Alexey Kardashevskiy wrote:
> On 04/30/2015 05:22 PM, David Gibson wrote:
> > On Sat, Apr 25, 2015 at 10:14:55PM +1000, Alexey Kardashevskiy wrote:
> >> At the moment only one group per container is supported.
> >> POWER8 CPUs have more flexible design and allows
On Thu, 2015-04-30 at 19:33 +1000, Alexey Kardashevskiy wrote:
On 04/30/2015 05:22 PM, David Gibson wrote:
On Sat, Apr 25, 2015 at 10:14:55PM +1000, Alexey Kardashevskiy wrote:
At the moment only one group per container is supported.
POWER8 CPUs have more flexible design and allows naving 2
On Mon, 2015-04-27 at 11:48 -0500, Christoph Lameter wrote:
> On Mon, 27 Apr 2015, Rik van Riel wrote:
>
> > Why would we want to avoid the sane approach that makes this thing
> > work with the fewest required changes to core code?
>
> Becaus new ZONEs are a pretty invasive change to the memory
On Mon, 2015-04-27 at 11:48 -0500, Christoph Lameter wrote:
On Mon, 27 Apr 2015, Rik van Riel wrote:
Why would we want to avoid the sane approach that makes this thing
work with the fewest required changes to core code?
Becaus new ZONEs are a pretty invasive change to the memory
On Fri, 2015-04-24 at 22:32 -0400, Rik van Riel wrote:
> > The result would be that the kernel would allocate only
> migratable
> > pages within the CCAD device's memory, and even then only if
> > memory was otherwise exhausted.
>
> Does it make sense to allocate the device's
On Fri, 2015-04-24 at 11:58 -0500, Christoph Lameter wrote:
> On Fri, 24 Apr 2015, Jerome Glisse wrote:
>
> > > What exactly is the more advanced version's benefit? What are the features
> > > that the other platforms do not provide?
> >
> > Transparent access to device memory from the CPU, you
On Fri, 2015-04-24 at 11:58 -0500, Christoph Lameter wrote:
On Fri, 24 Apr 2015, Jerome Glisse wrote:
What exactly is the more advanced version's benefit? What are the features
that the other platforms do not provide?
Transparent access to device memory from the CPU, you can map any
On Fri, 2015-04-24 at 22:32 -0400, Rik van Riel wrote:
The result would be that the kernel would allocate only
migratable
pages within the CCAD device's memory, and even then only if
memory was otherwise exhausted.
Does it make sense to allocate the device's page tables
On Thu, 2015-04-23 at 09:10 -0500, Christoph Lameter wrote:
> On Thu, 23 Apr 2015, Benjamin Herrenschmidt wrote:
>
> > > Anyone
> > > wanting performance (and that is the prime reason to use a GPU) would
> > > switch this off because the latencies are otherwise
On Thu, 2015-04-23 at 11:25 -0400, Austin S Hemmelgarn wrote:
> Looking at this whole conversation, all I see is two different views on
> how to present the asymmetric multiprocessing arrangements that have
> become commonplace in today's systems to userspace. Your model favors
> performance,
On Thu, 2015-04-23 at 11:25 -0400, Austin S Hemmelgarn wrote:
Looking at this whole conversation, all I see is two different views on
how to present the asymmetric multiprocessing arrangements that have
become commonplace in today's systems to userspace. Your model favors
performance,
On Thu, 2015-04-23 at 09:10 -0500, Christoph Lameter wrote:
On Thu, 23 Apr 2015, Benjamin Herrenschmidt wrote:
Anyone
wanting performance (and that is the prime reason to use a GPU) would
switch this off because the latencies are otherwise not controllable and
those may impact
On Wed, 2015-04-22 at 13:17 -0500, Christoph Lameter wrote:
>
> > But again let me stress that application that want to be in control will
> > stay in control. If you want to make the decission yourself about where
> > things should end up then nothing in all we are proposing will preclude
> >
On Wed, 2015-04-22 at 12:14 -0500, Christoph Lameter wrote:
>
> > Bottom line is we want today anonymous, share or file mapped memory
> > to stay the only kind of memory that exist and we want to choose the
> > backing store of each of those kind for better placement depending
> > on how memory
1201 - 1300 of 5350 matches
Mail list logo
