Unmaps that free page tables always flush the entire PID, which is
sub-optimal. Provide TLB range flushing with an additional PWC flush
that can be use for va range invalidations with PWC flush.
Time to munmap N pages of memory including last level page table
teardown (after mmap, touch)
The single page flush ceiling is the cut-off point at which we switch
from invalidating individual pages, to invalidating the entire process
address space in response to a range flush.
Introduce a local variant of this heuristic because local and global
tlbie have significantly different propertie
Currently for radix, flush_tlb_range flushes the entire PID, because
the Linux mm code does not tell us about page size here for THP vs
regular pages. This is quite sub-optimal for small mremap / mprotect
/ change_protection.
So implement va range flushes with two flush passes, one for each
page s
Move the barriers and range iteration down into the _tlbie* level,
which improves readability.
Signed-off-by: Nicholas Piggin
---
arch/powerpc/mm/tlb-radix.c | 70 ++---
1 file changed, 40 insertions(+), 30 deletions(-)
diff --git a/arch/powerpc/mm/tlb-ra
Short range flushes issue a sequences of tlbie(l) instructions for
individual effective addresses. These do not all require individual
barrier sequences, only one covering all tlbie(l) instructions.
Commit f7327e0ba3 ("powerpc/mm/radix: Remove unnecessary ptesync")
made a similar optimization for
Here's a random mix of performance improvements for radix TLB flushing
code. The main aims are to reduce the amount of translation that gets
invalidated, and to reduce global flushes where we can do local.
To that end, a parallel kernel compile benchmark using powerpc:tlbie
tracepoint shows a redu
Lazy save and restore of FP/Altivec means that a userspace process can
be sent to userspace with FP or Altivec disabled and loaded only as
required (by way of an FP/Altivec unavailable exception). Transactional
Memory complicates this situation as a transaction could be started
without FP/Altivec b
After handling a transactional FP, Altivec or VSX unavailable exception.
The return to userspace code will detect that the TIF_RESTORE_TM bit is
set and call restore_tm_state(). restore_tm_state() will call
restore_math() to ensure that the correct facilities are loaded.
This means that all the lo
Lazy save and restore of FP/Altivec means that a userspace process can
be sent to userspace with FP or Altivec disabled and loaded only as
required (by way of an FP/Altivec unavailable exception). Transactional
Memory complicates this situation as a transaction could be started
without FP/Altivec b
Lazy save and restore of FP/Altivec means that a userspace process can
be sent to userspace with FP or Altivec disabled and loaded only as
required (by way of an FP/Altivec unavailable exception). Transactional
Memory complicates this situation as a transaction could be started
without FP/Altivec b
DMA windows can only have a size of power of two on IODA2 hardware and
using memory_hotplug_max() to determine the upper limit won't work
correcly if it returns not power of two value.
This relaxes the check by rounding up the value returned by
memory_hotplug_max().
It is expected to impact DPDK
Hi all,
Could anybody review this patchset and take action on them? Thank you!
Best Regards
Qiang Zhao
> > -Original Message-
> > From: Zhao Qiang [mailto:qiang.z...@nxp.com]
> > Sent: Monday, August 07, 2017 11:07 AM
> > To: t...@linutronix.de
> > Cc: o...@buserror.net; Xiaobo Xie ; lin
On Tue, Oct 31, 2017 at 3:03 AM, Aneesh Kumar K.V
wrote:
>
>
> On 10/30/2017 06:08 PM, Balbir Singh wrote:
>>
>> +
>> +static void pnv_npu2_invalidate_helper(struct npu_context *npu_context,
>> + struct mm_struct *mm, unsigned long start,
>> + unsigned long end, bool fl
On Mon, 2017-10-30 at 10:15 +0100, Boris Brezillon wrote:
> On Tue, 10 Oct 2017 14:32:52 +1100
> Cyril Bur wrote:
>
> > V4: Rework and rethink.
> >
> > To recap:
> > Userspace MTD read()s/write()s and erases to powernv_flash become
> > calls into the OPAL firmware which subsequently handles flas
On 10/30/2017 06:08 PM, Balbir Singh wrote:
+
+static void pnv_npu2_invalidate_helper(struct npu_context *npu_context,
+ struct mm_struct *mm, unsigned long start,
+ unsigned long end, bool flush)
+{
+ unsigned long address;
+ bool is_thp;
+ unsigne
This makes the changes introduced in commit 83e840c770f2c5
("powerpc64/elfv1: Only dereference function descriptor for non-text
symbols") to be specific to the kprobe subsystem.
We previously changed ppc_function_entry() to always check the provided
address to confirm if it needed to be dereferenc
This reverts commit 83e840c770f2c5 ("powerpc64/elfv1: Only dereference
function descriptor for non-text symbols").
Chandan reported that on newer kernels, trying to enable function_graph
tracer on ppc64 (BE) locks up the system with the following trace:
Unable to handle kernel paging request fo
Chandan reported that trying to enable function_graph tracer on ppc64 BE
now locks up the system. This is due to prepare_ftrace_return() using
ppc_function_entry() for resolving return_to_handler(), which in turn
invokes kernel_text_address(), which also gets traced resulting in a
loop.
We add
"Aneesh Kumar K.V" writes:
> "Aneesh Kumar K.V" writes:
>
>
>> I looked at the perf data and with the test, we are doing larger number
>> of hash faults and then around 10k flush_hash_range. Can the small
>> improvement in number be due to the fact that we are not storing slot
>> number when doi
"Aneesh Kumar K.V" writes:
> I looked at the perf data and with the test, we are doing larger number
> of hash faults and then around 10k flush_hash_range. Can the small
> improvement in number be due to the fact that we are not storing slot
> number when doing an insert now?. Also in the flush
Hi all,
Today's linux-next merge of the powerpc tree got a conflict in:
arch/powerpc/kvm/powerpc.c
between commit:
ac64115a66c1 ("KVM: PPC: Fix oops when checking KVM_CAP_PPC_HTM")
from Linus' tree and commit:
2a3d6553cbd7 ("KVM: PPC: Tie KVM_CAP_PPC_HTM to the user-visible TM feature")
While reviewing the code I found that the flush assumes all
pages are of mmu_linear_psize, which is not correct. The patch
uses find_linux_pte to find the right page size and uses that
for launching the ATSD invalidation. A new helper is added
to abstract the invalidation from the various notifiers
On Friday 27 October 2017 03:04 PM, Anju T Sudhakar wrote:
Add ldbar spr to sysfs. The spr will hold thread level In-Memory Collection
(IMC)
counter configuration data.
Signed-off-by: Anju T Sudhakar
Acked-by: Madhavan Srinivasan
---
arch/powerpc/kernel/sysfs.c | 8
1 file chang
Paul Mackerras writes:
> On Fri, Oct 27, 2017 at 10:57:13AM +0530, Aneesh Kumar K.V wrote:
>>
>>
>> On 10/27/2017 10:04 AM, Paul Mackerras wrote:
>> >How do we interpret these numbers? Are they times, or speed? Is
>> >larger better or worse?
>>
>> Sorry for not including the details. They ar
It would be nice to be able to dump page tables in a particular
context.
eg: dumping vmalloc space:
0:mon> dv 0xd00037f0
pgd @ 0xc17c
pgdp @ 0xc17c00d8 = 0xf10b1000
pudp @ 0xc000f10b13f8 = 0xf10d
pmdp @ 0xc000f10d1ff8 = 0x
/commits/Anju-T-Sudhakar/powerpc-kernel-sysfs-Export-ldbar-spr-to-sysfs/20171030-155220
base: https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
config: powerpc-storcenter_defconfig (attached as .config)
compiler: powerpc-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce
On Tue, 10 Oct 2017 14:32:52 +1100
Cyril Bur wrote:
> V4: Rework and rethink.
>
> To recap:
> Userspace MTD read()s/write()s and erases to powernv_flash become
> calls into the OPAL firmware which subsequently handles flash access.
> Because the read()s, write()s or erases can be large (bounded
On Tue, 10 Oct 2017 14:33:02 +1100
Cyril Bur wrote:
> The OPAL calls performed in this driver shouldn't be using
> opal_async_wait_response() as this performs a wait_event() which, on
> long running OPAL calls could result in hung task warnings. wait_event()
> prevents timely signal delivery whic
On Tue, 10 Oct 2017 14:32:56 +1100
Cyril Bur wrote:
> Because the MTD core might split up a read() or write() from userspace
> into several calls to the driver, we may fail to get a token but already
> have done some work, best to return -EINTR back to userspace and have
> them decide what to do.
On Tue, 10 Oct 2017 14:32:55 +1100
Cyril Bur wrote:
Can you please add a short description here?
Once done you can add
Acked-by: Boris Brezillon
> Signed-off-by: Cyril Bur
> ---
> drivers/mtd/devices/powernv_flash.c | 16 ++--
> 1 file changed, 6 insertions(+), 10 deletions(-)
>
On Tue, 10 Oct 2017 14:32:54 +1100
Cyril Bur wrote:
> While this driver expects to interact asynchronously, OPAL is well
> within its rights to return OPAL_SUCCESS to indicate that the operation
> completed without the need for a callback. We shouldn't treat
> OPAL_SUCCESS as an error rather we s
On Tue, 10 Oct 2017 14:32:53 +1100
Cyril Bur wrote:
> BUG_ON() should be reserved in situations where we can not longer
> guarantee the integrity of the system. In the case where
> powernv_flash_async_op() receives an impossible op, we can still
> guarantee the integrity of the system.
>
> Signe
Paul Mackerras writes:
> On Fri, Oct 27, 2017 at 10:57:13AM +0530, Aneesh Kumar K.V wrote:
>>
>>
>> On 10/27/2017 10:04 AM, Paul Mackerras wrote:
>> >How do we interpret these numbers? Are they times, or speed? Is
>> >larger better or worse?
>>
>> Sorry for not including the details. They ar
Hi,
A warning is being triggered while booting mainline kernel on ppc
machine.
Machine Type: Power 9
Kernel : 4.14.0-rc6
gcc: 4.8.5
Test : Boot
Boot logs:
--
hv-24x7: found a duplicate event PM_CAPP1_XPT_MSG_SENT_GT_16_LE_64, ct=1
hv-24x7: found a duplicate event
PM_CAPP1_XPT_MSG_SENT_TS
34 matches
Mail list logo
