Hi Michael,
These patches were posted a month back. We don't have any review
comments to handle at this time. Can you pull these patches to your tree?
Please, do let me know if you want me to rebase these patches to a
different tree (like Arnaldo's/tip etc).
On 02/27/2015 03:13 PM, Hemant Kum
Hi Shuah,
Today's linux-next merge of the kselftest tree got a conflict in
tools/testing/selftests/powerpc/Makefile between commit a908f5de3b10
("selftests/powerpc: Rename TARGETS in powerpc selftests makefile")
from the powerpc-mpe tree and commit 6faeeea44b84 ("selftests: Add
install support for
Benjamin Herrenschmidt writes:
> On Mon, 2015-03-23 at 20:30 +0530, Aneesh Kumar K.V wrote:
>
>> -static inline pte_t *lookup_linux_ptep(pgd_t *pgdir, unsigned long hva,
>> +static inline pte_t lookup_linux_pte(pgd_t *pgdir, unsigned long hva,
>> unsigned long *p
On 03/24/2015 07:34 AM, Michael Ellerman wrote:
> On Fri, 2015-03-20 at 14:34 +0530, Anshuman Khandual wrote:
>> On 03/19/2015 10:13 AM, Sam Bobroff wrote:
>>> This patch changes the syscall handler to doom (tabort) active
>>> transactions when a syscall is made and return immediately without
>>> p
Now we could use pci_scan_host_bridge() to scan
pci buses, provide powerpc specific pci_host_bridge_ops.
Signed-off-by: Yijing Wang
CC: Benjamin Herrenschmidt
CC: linuxppc-dev@lists.ozlabs.org
---
arch/powerpc/kernel/pci-common.c | 60 +++--
1 files changed, 37
On Tue, Mar 24, 2015 at 12:22:25PM +1100, David Gibson wrote:
>On Tue, Mar 24, 2015 at 09:47:54AM +1100, Gavin Shan wrote:
>> On Mon, Mar 23, 2015 at 10:14:59AM -0600, Alex Williamson wrote:
>> >On Mon, 2015-03-23 at 16:20 +1100, Gavin Shan wrote:
>> >> On Mon, Mar 23, 2015 at 04:10:20PM +1100, Dav
On Tue, 2015-02-03 at 16:36 +1100, David Gibson wrote:
> The bt8xx PCI DVB driver includes a powerpc specific hack, using one of
> the powerpc specific byteswapping functions in an IO helper macro.
>
> There's no reason to use the powerpc specific function instead of a
> generic byteswap, so this
Hi Linus,
Please pull some powerpc fixes for 4.0:
The following changes since commit 06e5801b8cb3fc057d88cb4dc03c0b64b2744cda:
Linux 4.0-rc4 (2015-03-15 17:38:20 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/mpe/linux.git tags/powerpc-4.0-3
f
From: Benjamin Herrenschmidt
Date: Tue, 24 Mar 2015 13:08:10 +1100
> For the large pool, we don't keep a hint so we don't know it's
> wrapped, in fact we purposefully don't use a hint to limit
> fragmentation on it, but then, it should be used rarely enough that
> flushing always is, I suspect, a
On Mon, 2015-03-23 at 21:44 -0400, David Miller wrote:
> From: Benjamin Herrenschmidt
> Date: Tue, 24 Mar 2015 09:21:05 +1100
>
> > Dave, what's your feeling there ? Does anybody around still have
> > some HW that we can test with ?
>
> I don't see what the actual problem is.
>
> Even if you us
On Fri, 2015-03-20 at 14:34 +0530, Anshuman Khandual wrote:
> On 03/19/2015 10:13 AM, Sam Bobroff wrote:
> > This patch changes the syscall handler to doom (tabort) active
> > transactions when a syscall is made and return immediately without
> > performing the syscall.
> >
> > Currently, the syst
On Tue, 2015-03-24 at 12:52 +1100, Sam Bobroff wrote:
> On 20/03/15 20:25, Anshuman Khandual wrote:
> > On 03/19/2015 10:13 AM, Sam Bobroff wrote:
> >> Check that a syscall made during an active transaction will fail with
> >> the correct failure code and that one made during a suspended
> >> trans
benh> It might be sufficient to add a flush counter and compare it between runs
benh> if actual wall-clock benchmarks are too hard to do (especially if you
benh> don't have things like very fast network cards at hand).
benh>
benh> Number of flush / number of packets might be a sufficient metric, it
On Tue, Mar 24, 2015 at 10:22:26AM +1100, Daniel Axtens wrote:
>> +
>> +/* Do some magic shift */
>> +ret = pnv_pci_vf_resource_shift(pdev, pdn->offset);
>
>
>Given that you're already doing a version 15, would it be possible to
>include a more informative comment than "Do s
On 20/03/15 20:25, Anshuman Khandual wrote:
> On 03/19/2015 10:13 AM, Sam Bobroff wrote:
>> Check that a syscall made during an active transaction will fail with
>> the correct failure code and that one made during a suspended
>> transaction will succeed.
>>
>> Signed-off-by: Sam Bobroff
>
> The
From: Benjamin Herrenschmidt
Date: Tue, 24 Mar 2015 09:21:05 +1100
> Dave, what's your feeling there ? Does anybody around still have
> some HW that we can test with ?
I don't see what the actual problem is.
Even if you use multiple pools, which we should for scalability on
sun4u too, just do t
On Tue, Mar 24, 2015 at 09:47:54AM +1100, Gavin Shan wrote:
> On Mon, Mar 23, 2015 at 10:14:59AM -0600, Alex Williamson wrote:
> >On Mon, 2015-03-23 at 16:20 +1100, Gavin Shan wrote:
> >> On Mon, Mar 23, 2015 at 04:10:20PM +1100, David Gibson wrote:
> >> >On Mon, Mar 23, 2015 at 04:03:59PM +1100, G
On (03/24/15 11:47), Benjamin Herrenschmidt wrote:
>
> Yes, pass a function pointer argument that can be NULL or just make it a
> member of the iommu_allocator struct (or whatever you call it) passed to
> the init function and that can be NULL. My point is we don't need a
> separate "ops" structur
On Wed, 2015-03-04 at 12:22 -0800, Tyrel Datwyler wrote:
> During suspend/migration operation we must wait for the VASI state reported
> by the hypervisor to become Suspending prior to making the ibm,suspend-me
> RTAS call. Calling routines to rtas_ibm_supend_me() pass a vasi_state variable
> that
On Mon, 2015-03-23 at 19:19 -0400, Sowmini Varadhan wrote:
> What I've tried to do is to have a bool large_pool arg passed
> to iommu_tbl_pool_init. In my observation (instrumented for scsi, ixgbe),
> we never allocate more than 4 pages at a time, so I pass in
> large_pool == false for all the s
On Mon, 2015-03-23 at 19:08 -0400, Sowmini Varadhan wrote:
> > Sowmini, I see various options for the second choice. We could stick to
> > 1 pool, and basically do as before, ie, if we fail on the first pass of
> > alloc, it means we wrap around and do a flush, I don't think that will
> > cause a
For PowerNV platform, running on top of skiboot, all PE level reset
should be routed to firmware if the bridge of the PE primary bus has
device-node property "ibm,reset-by-firmware". Otherwise, the kernel
has to issue hot reset on PE's primary bus despite the requested reset
types, which is the beh
In hotplug case, function pcibios_add_pci_devices() is called to
rescan the specified PCI bus, which might not have any child devices.
Access to the PCI bus's child device node will cause kernel crash
without exception. The patch adds condition of skipping scanning
PCI bus without child devices, in
The patches intend to utilize the PCI slot reset capability exposed from
the skiboot firmware, which requires corresponding changes as follows:
Changelog
=
v2 -> v3
* Rebased to Richard's SRIOV patchset.
* Removed hotplug part, which needs rework.
v1 -> v2
* Keep opal_pci_reinit()
Function pnv_pci_reset_secondary_bus() is used to reset specified
PCI bus, which is leaded by root complex or PCI bridge. That means
the function shouldn't be called on PCI root bus and the patch
removes the logic for that case.
Also, some adapters beneath the indicated PCI bus may require
fundame
On Mon, 2015-03-23 at 15:08 -0600, Alex Williamson wrote:
>
> I don't know what you're doing on POWER, I thought groups were
> equivalent to PEs, but on x86 we learn about isolation of PCI functions
> by standard PCI properties. Devices need to tell us that they're
> isolated via ACS capabilities
On Thu, 2015-05-03 at 02:25:38 UTC, Tyrel Datwyler wrote:
> The /sys/kernel/mobility/migration interface was added all the way back
> in 2.6.37. However, the drmgr userspace tool was never augmented to use
> this interface to perfrom migrations. Instead it has continued using a
> faux rtas call cou
On Mon, 2015-03-23 at 17:07 -0300, casca...@linux.vnet.ibm.com wrote:
>
> I agree with you here. I think the bigger issue is that we are not
> making sure VFIO is secure, allowing functions to be assigned
> separately to different guests, even when we cannot guarantee we can
> safely reset a singl
On Mar 23, 2015 7:13 PM, "Sowmini Varadhan"
wrote:
>
> On (03/24/15 09:21), Benjamin Herrenschmidt wrote:
> >
> > So we have two choices here that I can see:
> >
> > - Keep that old platform use the old/simpler allocator
>
> Problem with that approach is that the base "struct iommu" structure
> f
On Mon, 2015-03-23 at 20:30 +0530, Aneesh Kumar K.V wrote:
> -static inline pte_t *lookup_linux_ptep(pgd_t *pgdir, unsigned long hva,
> +static inline pte_t lookup_linux_pte(pgd_t *pgdir, unsigned long hva,
>unsigned long *pte_sizep)
> {
> pte_t *ptep;
>
On Thu, 2015-02-26 at 09:26 -0600, Emil Medve wrote:
> From: Igal Liberman
>
> Signed-off-by: Igal Liberman
> ---
> arch/powerpc/boot/dts/fsl/b4si-post.dtsi| 11 +++
> arch/powerpc/boot/dts/fsl/p2041si-post.dtsi | 8
> arch/powerpc/boot/dts/fsl/p3041si-post.dtsi | 8 +
On Fri, 2015-02-27 at 09:16 -0600, Emil Medve wrote:
> From: Kumar Gala
>
> Signed-off-by: Kumar Gala
> Signed-off-by: Geoff Thorpe
> Signed-off-by: Hai-Ying Wang
> Signed-off-by: Chunhe Lan
> Signed-off-by: Poonam Aggrwal
> [Emil Medve: Sync with the upstream binding]
> Signed-off-by: Emil
On Fri, 2015-03-20 at 11:06 +0800, Wei Yang wrote:
> On PowerNV platform, resource position in M64 BAR implies the PE# the
> resource belongs to. In some cases, adjustment of a resource is necessary
> to locate it to a correct position in M64 BAR .
>
> This patch adds pnv_pci_vf_resource_shift() t
On (03/24/15 09:36), Benjamin Herrenschmidt wrote:
>
> - One pool only
>
> - Whenever the allocation is before the previous hint, do a flush, that
> should only happen if a wrap around occurred or in some cases if the
> device DMA mask forced it. I think we always update the hint whenever we
>
On (03/24/15 09:21), Benjamin Herrenschmidt wrote:
>
> So we have two choices here that I can see:
>
> - Keep that old platform use the old/simpler allocator
Problem with that approach is that the base "struct iommu" structure
for sparc gets a split personality: the older one is used with
the o
On Mon, Mar 23, 2015 at 06:40:34AM -0600, Alex Williamson wrote:
>On Mon, 2015-03-23 at 15:40 +1100, Gavin Shan wrote:
>> On Sun, Mar 22, 2015 at 10:06:01PM -0600, Alex Williamson wrote:
>> >On Mon, 2015-03-23 at 14:56 +1100, Gavin Shan wrote:
>> >> On Sun, Mar 22, 2015 at 09:34:33PM -0600, Alex Wi
On Mon, 2015-03-23 at 15:28 -0400, Pranith Kumar wrote:
> Hello,
>
> I see frequent lockups with the latest rc5 kernel on a mac mini power
> pc 32 system. I see the following in dmesg. I could git bisect, but
> was wondering if you guys have seen this before and if anyone has any
> pointers which
On Mon, Mar 23, 2015 at 10:14:59AM -0600, Alex Williamson wrote:
>On Mon, 2015-03-23 at 16:20 +1100, Gavin Shan wrote:
>> On Mon, Mar 23, 2015 at 04:10:20PM +1100, David Gibson wrote:
>> >On Mon, Mar 23, 2015 at 04:03:59PM +1100, Gavin Shan wrote:
>> >> On Mon, Mar 23, 2015 at 02:43:03PM +1100, Dav
On Mon, 2015-03-23 at 15:05 -0400, David Miller wrote:
> From: Sowmini Varadhan
> Date: Mon, 23 Mar 2015 12:54:06 -0400
>
> > If it was only an optimization (i.e., removing it would not break
> > any functionality), and if this was done for older hardware,
> > and *if* we believe that the directi
On Mon, 2015-03-23 at 12:54 -0400, Sowmini Varadhan wrote:
> If it was only an optimization (i.e., removing it would not break
> any functionality), and if this was done for older hardware,
> and *if* we believe that the direction of most architectures is to
> follow the sun4v/HV model, then, giv
On Mon, 2015-03-23 at 15:05 -0400, David Miller wrote:
> From: Sowmini Varadhan
> Date: Mon, 23 Mar 2015 12:54:06 -0400
>
> > If it was only an optimization (i.e., removing it would not break
> > any functionality), and if this was done for older hardware,
> > and *if* we believe that the directi
Michael Ellerman [m...@ellerman.id.au] wrote:
| On Tue, 2015-17-02 at 22:00:27 UTC, Sukadev Bhattiprolu wrote:
| > Use pr_notice_ratelimited() to log error messages and remove
| > the 'success_expected' parameter.
|
| I don't understand how this is equivalent?
They are two unrelated changes that
Michael Ellerman [m...@ellerman.id.au] wrote:
| > +static void start_24x7_get_data(struct hv_24x7_request_buffer
*request_buffer,
| > + struct hv_24x7_data_result_buffer *result_buffer)
| > +{
|
| Just init_24x7_request() ?
Sure.
|
| > +
| > + memset(request_buffer, 0, 4096
Michael Ellerman [m...@ellerman.id.au] wrote:
| On Tue, 2015-17-02 at 22:00:34 UTC, Sukadev Bhattiprolu wrote:
| > Add missing put_cpu_var() for 24x7 requests.
|
| When did it go missing? I assume in upstream, in which case this should be a
| separate patch which I could merge for 4.0.
It went mi
On 23 March 2015 19:36:44 GMT+11:00, Alexander Graf wrote:
>
>
>On 17.03.15 11:44, Mahesh J Salgaonkar wrote:
>> From: Mahesh Salgaonkar
>>
>> commit id 2ba9f0d has changed CONFIG_KVM_BOOK3S_64_HV to tristate to
>allow
>> HV/PR bits to be built as modules. But the MCE code still depends on
>>
On Mon, 2015-03-23 at 17:07 -0300, casca...@linux.vnet.ibm.com wrote:
> On Mon, Mar 23, 2015 at 06:40:34AM -0600, Alex Williamson wrote:
> > On Mon, 2015-03-23 at 15:40 +1100, Gavin Shan wrote:
> > > On Sun, Mar 22, 2015 at 10:06:01PM -0600, Alex Williamson wrote:
> > > >On Mon, 2015-03-23 at 14:56
On Mon, Mar 23, 2015 at 8:16 PM, Geert Uytterhoeven
wrote:
> JFYI, when comparing v4.0-rc5[1] to v4.0-rc4[3], the summaries are:
> - build errors: +19/-7
+ /home/kisskb/slave/src/drivers/gpu/drm/bridge/ptn3460.c: error:
implicit declaration of function 'devm_gpiod_get'
[-Werror=implicit-funct
On 03/04/2015 12:22 PM, Tyrel Datwyler wrote:
> During suspend/migration operation we must wait for the VASI state reported
> by the hypervisor to become Suspending prior to making the ibm,suspend-me
> RTAS call. Calling routines to rtas_ibm_supend_me() pass a vasi_state variable
> that exposes the
On 03/04/2015 06:25 PM, Tyrel Datwyler wrote:
> The /sys/kernel/mobility/migration interface was added all the way back
> in 2.6.37. However, the drmgr userspace tool was never augmented to use
> this interface to perfrom migrations. Instead it has continued using a
> faux rtas call coupled with pe
On Mon, Mar 23, 2015 at 06:40:34AM -0600, Alex Williamson wrote:
> On Mon, 2015-03-23 at 15:40 +1100, Gavin Shan wrote:
> > On Sun, Mar 22, 2015 at 10:06:01PM -0600, Alex Williamson wrote:
> > >On Mon, 2015-03-23 at 14:56 +1100, Gavin Shan wrote:
> > >> On Sun, Mar 22, 2015 at 09:34:33PM -0600, Ale
Hello,
I see frequent lockups with the latest rc5 kernel on a mac mini power
pc 32 system. I see the following in dmesg. I could git bisect, but
was wondering if you guys have seen this before and if anyone has any
pointers which can reduce my bisect search space.
Thanks!
[ 5735.022209] Unable t
On (03/23/15 15:05), David Miller wrote:
>
> Why add performance regressions to old machines who already are
> suffering too much from all the bloat we are constantly adding to the
> kernel?
I have no personal opinion on this- it's a matter of choosing
whether we want to have some extra baggage
From: Sowmini Varadhan
Date: Mon, 23 Mar 2015 12:54:06 -0400
> If it was only an optimization (i.e., removing it would not break
> any functionality), and if this was done for older hardware,
> and *if* we believe that the direction of most architectures is to
> follow the sun4v/HV model, then,
On Monday 23 March 2015, Benjamin Herrenschmidt wrote:
> On Mon, 2015-03-23 at 07:04 +0100, Arnd Bergmann wrote:
> >
> > My guess is that the ARM code so far has been concerned mainly with
> > getting things to work in the first place, but scalability problems
> > will only be seen when there are
From: Mahesh Salgaonkar
commit id 2ba9f0d changed CONFIG_KVM_BOOK3S_64_HV to tristate to allow
HV/PR bits to be built as modules. But the MCE code still depends on
CONFIG_KVM_BOOK3S_64_HV which is wrong. When user selects
CONFIG_KVM_BOOK3S_64_HV=m to build HV/PR bits as a separate module the
rele
From: Mahesh Salgaonkar
For the machine check interrupt that happens while we are in the guest,
kvm layer attempts the recovery, and then delivers the machine check interrupt
directly to the guest if recovery fails. On successful recovery we go back to
normal functioning of the guest. But there c
On (03/23/15 12:29), David Miller wrote:
>
> In order to elide the IOMMU flush as much as possible, I implemnented
> a scheme for sun4u wherein we always allocated from low IOMMU
> addresses to high IOMMU addresses.
>
> In this regime, we only need to flush the IOMMU when we rolled over
> back to
From: Sowmini Varadhan
Date: Sun, 22 Mar 2015 15:27:26 -0400
> That leaves only the odd iommu_flushall() hook, I'm trying
> to find the history behind that (needed for sun4u platforms,
> afaik, and not sure if there are other ways to achieve this).
In order to elide the IOMMU flush as much as po
On Mon, 2015-03-23 at 16:20 +1100, Gavin Shan wrote:
> On Mon, Mar 23, 2015 at 04:10:20PM +1100, David Gibson wrote:
> >On Mon, Mar 23, 2015 at 04:03:59PM +1100, Gavin Shan wrote:
> >> On Mon, Mar 23, 2015 at 02:43:03PM +1100, David Gibson wrote:
> >> >On Mon, Mar 23, 2015 at 12:56:36PM +1100, Gavi
We can disable a THP split or a hugepage collapse by disabling irq.
We do send IPI to all the cpus in the early part of split/collapse,
and disabling local irq ensure we don't make progress with
split/collapse. Before using the pte_t pointer returned by
find_linux_pte_or_hugepte(), we need to make
Now we could use pci_scan_host_bridge() to scan
pci buses, provide powerpc specific pci_host_bridge_ops.
Signed-off-by: Yijing Wang
CC: Benjamin Herrenschmidt
CC: linuxppc-dev@lists.ozlabs.org
---
arch/powerpc/kernel/pci-common.c | 60 +++--
1 files changed, 37
On Mon, 2015-03-23 at 15:40 +1100, Gavin Shan wrote:
> On Sun, Mar 22, 2015 at 10:06:01PM -0600, Alex Williamson wrote:
> >On Mon, 2015-03-23 at 14:56 +1100, Gavin Shan wrote:
> >> On Sun, Mar 22, 2015 at 09:34:33PM -0600, Alex Williamson wrote:
> >> >On Mon, 2015-03-23 at 14:02 +1100, Gavin Shan w
Dave Chinner reported the following on https://lkml.org/lkml/2015/3/1/226
Across the board the 4.0-rc1 numbers are much slower, and the degradation
is far worse when using the large memory footprint configs. Perf points
straight at the cause - this is from 4.0-rc1 on the "-o bhash=101073" co
Protecting a PTE to trap a NUMA hinting fault clears the writable bit
and further faults are needed after trapping a NUMA hinting fault to
set the writable bit again. This patch preserves the writable bit when
trapping NUMA hinting faults. The impact is obvious from the number
of minor faults trapp
These are three follow-on patches based on the xfsrepair workload Dave
Chinner reported was problematic in 4.0-rc1 due to changes in page table
management -- https://lkml.org/lkml/2015/3/1/226.
Much of the problem was reduced by commit 53da3bc2ba9e ("mm: fix up numa
read-only thread grouping logic
Threads that share writable data within pages are grouped together as
related tasks. This decision is based on whether the PTE is marked dirty
which is subject to timing races between the PTE scanner update and when the
application writes the page. If the page is file-backed, then background
flushe
On Fri, Mar 20, 2015 at 10:02:23AM -0700, Linus Torvalds wrote:
> On Thu, Mar 19, 2015 at 9:13 PM, Dave Chinner wrote:
> >
> > Testing now. It's a bit faster - three runs gave 7m35s, 7m20s and
> > 7m36s. IOWs's a bit better, but not significantly. page migrations
> > are pretty much unchanged, too
On 27.02.2015 22:54, Benjamin Herrenschmidt wrote:
On Fri, 2015-02-27 at 09:28 +0200, Purcareata Bogdan wrote:
Ping?
What is the ping for ?
Ben.
Hello Ben,
I just wanted to check with you what's the current status of these
patches. I noticed in patchwork [1][2][3] that the patches are mar
On Mon, 2015-03-23 at 07:04 +0100, Arnd Bergmann wrote:
>
> My guess is that the ARM code so far has been concerned mainly with
> getting things to work in the first place, but scalability problems
> will only be seen when there are faster CPU cores become available.
In any case, I think this is
On 03/19/2015 04:20 AM, Michael Neuling wrote:
> On Thu, 2015-03-19 at 09:45 +1100, Michael Neuling wrote:
>> On Wed, 2015-03-18 at 13:53 +0100, Ulrich Weigand wrote:
>>> Michael Neuling wrote on 23.02.2015 05:51:50:
>>>
Sorry for the slow response.
>>>
>>> Same here :-(
>>
>> I'm going to br
On 23/03/2015 09:52, Ingo Molnar wrote:
>
> * Laurent Dufour wrote:
>
>> Some architecture would like to be triggered when a memory area is moved
>> through the mremap system call.
>>
>> This patch is introducing a new arch_remap mm hook which is placed in the
>> path of mremap, and is called be
* Laurent Dufour wrote:
> Some architecture would like to be triggered when a memory area is moved
> through the mremap system call.
>
> This patch is introducing a new arch_remap mm hook which is placed in the
> path of mremap, and is called before the old area is unmapped (and the
> arch_unma
On 17.03.15 11:44, Mahesh J Salgaonkar wrote:
> From: Mahesh Salgaonkar
>
> commit id 2ba9f0d has changed CONFIG_KVM_BOOK3S_64_HV to tristate to allow
> HV/PR bits to be built as modules. But the MCE code still depends on
> CONFIG_KVM_BOOK3S_64_HV which is wrong. When user selects
> CONFIG_KVM_
73 matches
Mail list logo
