On Fri, Aug 10, 2018 at 09:45:33AM -0700, Srikar Dronamraju wrote:
> available: 4 nodes (0-3)
> node 0 cpus: 0 1 2 3 4 5 6 7 32 33 34 35 36 37 38 39 64 65 66 67 68 69 70 71
> 96 97 98 99 100 101 102 103 128 129 130 131 132 133 134 135 160 161 162 163
> 164 165 166 167 192 193 194 195 196 197 198
On Fri, Aug 10, 2018 at 10:30:19PM +0530, Srikar Dronamraju wrote:
> With commit 051f3ca02e46 ("sched/topology: Introduce NUMA identity node
> sched domain") scheduler introduces an new numa level. However on shared
> lpars like powerpc, this extra sched domain creation can lead to
> repeated rcu s
On Mon, Aug 27, 2018 at 05:26:53AM -0700, H. Peter Anvin wrote:
> _THIS_IP_, however, is completely ill-defined, other than being an
> address *somewhere* in the same global function (not even necessarily
> the same function if the function is static!) As my experiment show, in
> many (nearly) ca
On Sun, Aug 26, 2018 at 07:52:59PM -0700, Nick Desaulniers wrote:
> On Sun, Aug 26, 2018 at 1:25 PM Linus Torvalds
> > Instead, maybe we could encourage something like
> >
> > struct kernel_loc { const char *file; const char *fn; int line; };
> >
> > #define __GEN_LOC__(n) \
> > ({ sta
On Tue, Aug 21, 2018 at 04:02:58AM -0700, Srikar Dronamraju wrote:
> * Srikar Dronamraju [2018-08-10 22:30:18]:
>
> > With commit 051f3ca02e46 ("sched/topology: Introduce NUMA identity node
> > sched domain") scheduler introduces an new numa level. However this
> > leads to numa topology on 2 nod
On Thu, Jul 19, 2018 at 10:04:09AM -0700, Andy Lutomirski wrote:
> I added some more arch maintainers. The idea here is that, on x86 at
> least, task->active_mm and all its refcounting is pure overhead. When
> a process exits, __mmput() gets called, but the core kernel has a
> longstanding "optim
Commit-ID: aef92a8bed25d03b8f03ce499a56e8e8e5e2c05e
Gitweb: https://git.kernel.org/tip/aef92a8bed25d03b8f03ce499a56e8e8e5e2c05e
Author: Peter Zijlstra
AuthorDate: Tue, 10 Jul 2018 13:42:10 +0200
Committer: Ingo Molnar
CommitDate: Tue, 10 Jul 2018 17:56:22 +0200
watchdog/softlockup
On Mon, Jul 09, 2018 at 11:40:14PM +0530, Abdul Haleem wrote:
> Thanks Peter for the patch, build and boot is fine.
>
> Reported-and-tested-by: Abdul Haleem
Excellent, Ingo can you stick this in?
---
Subject: watchdog/softlockup: Fix SOFTLOCKUP_DETECTOR=n build
From: Peter Zijlstra
On Mon, Jul 09, 2018 at 03:21:23PM +0530, Abdul Haleem wrote:
> Greeting's
>
> Today's next fails to build on powerpc with below error
>
> kernel/cpu.o:(.data.rel+0x18e0): undefined reference to
> `lockup_detector_online_cpu'
> ld: BFD version 2.26.1-1.fc25 assertion fail elf64-ppc.c:14734
> kern
On Tue, Jun 12, 2018 at 05:57:37PM -0700, Ricardo Neri wrote:
+static bool is_hpet_wdt_interrupt(struct hpet_hld_data *hdata)
+{
+ unsigned long this_isr;
+ unsigned int lvl_trig;
+
+ this_isr = hpet_readl(HPET_STATUS) & BIT(hdata->num);
+
+ lvl_trig = hpet_readl(HPET_Tn_CF
On Tue, Jun 12, 2018 at 05:57:34PM -0700, Ricardo Neri wrote:
> The current default implementation of the hardlockup detector assumes that
> it is implemented using perf events.
The sparc and powerpc things are very much not using perf.
On Wed, Jun 13, 2018 at 05:41:41PM +1000, Nicholas Piggin wrote:
> On Tue, 12 Jun 2018 17:57:32 -0700
> Ricardo Neri wrote:
>
> > Instead of exposing individual functions for the operations of the NMI
> > watchdog, define a common interface that can be used across multiple
> > implementations.
>
On Tue, Jun 12, 2018 at 05:57:23PM -0700, Ricardo Neri wrote:
> diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h
> index 5426627..dbc5e02 100644
> --- a/include/linux/interrupt.h
> +++ b/include/linux/interrupt.h
> @@ -61,6 +61,8 @@
> *interrupt handler after sus
On Thu, May 17, 2018 at 09:19:49AM +0800, Boqun Feng wrote:
> On Wed, May 16, 2018 at 04:13:16PM -0400, Mathieu Desnoyers wrote:
> > and that x86 calls it from syscall_return_slowpath() (which AFAIU is
> > now used in the fast-path since KPTI), I wonder where we should call
>
> So we actually det
On Mon, Apr 30, 2018 at 06:44:26PM -0400, Mathieu Desnoyers wrote:
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index c32a181a7cbb..ed21a777e8c6 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -223,6 +223,7 @@ config PPC
> select HAVE_SYSCALL_TRACEPOINTS
On Tue, Mar 13, 2018 at 06:59:47PM +0100, Laurent Dufour wrote:
> This change is inspired by the Peter's proposal patch [1] which was
> protecting the VMA using SRCU. Unfortunately, SRCU is not scaling well in
> that particular case, and it is introducing major performance degradation
> due to exce
On Tue, Mar 13, 2018 at 07:32:59PM +0100, Michal Suchanek wrote:
> Copypasta from original gmb() and rfi implementation
Actual real changelogs would be very welcome. Seeing as I've not seen
these mythical RFI patches, this leaves one quite puzzled :-)
On Thu, Jan 25, 2018 at 01:13:21PM +0100, Petr Mladek wrote:
> > What I was getting at, the klp stuff is the very first thing we run when
> > we schedule the idle task, but its placed at the very end of the
> > function. This is confusing.
>
> I see.
>
>
> > The above still doesn't help with sol
On Thu, Jan 25, 2018 at 11:24:14AM +0100, Petr Mladek wrote:
> On Thu 2018-01-25 10:04:44, Peter Zijlstra wrote:
> > On Mon, Feb 13, 2017 at 07:42:40PM -0600, Josh Poimboeuf wrote:
> > > diff --git a/kernel/sched/idle.c b/kernel/sched/idle.c
> > > index 6a4bae0..a8b3f1
On Mon, Feb 13, 2017 at 07:42:40PM -0600, Josh Poimboeuf wrote:
> diff --git a/kernel/sched/idle.c b/kernel/sched/idle.c
> index 6a4bae0..a8b3f1a 100644
> --- a/kernel/sched/idle.c
> +++ b/kernel/sched/idle.c
> @@ -9,6 +9,7 @@
> #include
> #include
> #include
> +#include
>
> #include
>
On Tue, Jan 09, 2018 at 03:54:45AM +1100, Michael Ellerman wrote:
> diff --git a/arch/powerpc/kvm/book3s_rmhandlers.S
> b/arch/powerpc/kvm/book3s_rmhandlers.S
> index 42a4b237df5f..34a5adeff084 100644
> --- a/arch/powerpc/kvm/book3s_rmhandlers.S
> +++ b/arch/powerpc/kvm/book3s_rmhandlers.S
> @@ -4
> AFAIU the scheduler rq->lock is held while preemption is disabled.
> synchronize_sched() is used here to ensure that all pre-existing
> preempt-off critical sections have completed.
>
> So saying that we use synchronize_sched() to synchronize with rq->lock
> would be stretching the truth a bit.
On Thu, Oct 05, 2017 at 04:02:06PM +, Mathieu Desnoyers wrote:
> - On Oct 5, 2017, at 8:12 AM, Peter Zijlstra pet...@infradead.org wrote:
>
> > On Wed, Oct 04, 2017 at 02:37:53PM -0700, Paul E. McKenney wrote:
> >> diff --git a/arch/powerpc/kernel/membarrier.c
>
On Thu, Oct 05, 2017 at 02:12:50PM +0200, Peter Zijlstra wrote:
> On Wed, Oct 04, 2017 at 02:37:53PM -0700, Paul E. McKenney wrote:
> > diff --git a/arch/powerpc/kernel/membarrier.c
> > b/arch/powerpc/kernel/membarrier.c
> > new file mode 100644
> > index
On Wed, Oct 04, 2017 at 02:37:53PM -0700, Paul E. McKenney wrote:
> diff --git a/arch/powerpc/kernel/membarrier.c
> b/arch/powerpc/kernel/membarrier.c
> new file mode 100644
> index ..b0d79a5f5981
> --- /dev/null
> +++ b/arch/powerpc/kernel/membarrier.c
> @@ -0,0 +1,45 @@
> +void memb
On Fri, Sep 29, 2017 at 09:38:53PM +1000, Nicholas Piggin wrote:
> Not really. There is some ability to hold onto a line for a time, but
> there is no way to starve them, let alone starve hundreds of other
> CPUs. They will request the cacheline exclusive and eventually get it.
OK, hardware fairn
On Fri, Sep 29, 2017 at 02:27:57AM +1000, Nicholas Piggin wrote:
> The biggest power boxes are more tightly coupled than those big
> SGI systems, but even so just plodding along taking and releasing
> locks in turn would be fine on those SGI ones as well really. Not DoS
> level. This is not a sing
On Fri, Sep 29, 2017 at 01:01:12AM +1000, Nicholas Piggin wrote:
> That's fine. If a user is not bound to a subset of CPUs, they could
> also cause disturbances with other syscalls and faults, taking locks,
> causing tlb flushes and IPIs and things.
So on the big SGI class machines we've had troub
On Fri, Sep 15, 2017 at 02:38:51PM +0200, Laurent Dufour wrote:
> > /*
> > * well... answering your question - it seems raw versions of seqcount
> > * functions don't call lockdep's lock_acquire/lock_release...
> > *
> > * but I have never told you that. never.
> > */
>
> Hum... I'm not
On Thu, Aug 31, 2017 at 12:25:16PM +0530, Anshuman Khandual wrote:
> On 08/30/2017 03:02 PM, Laurent Dufour wrote:
> > On 30/08/2017 07:58, Peter Zijlstra wrote:
> >> On Wed, Aug 30, 2017 at 10:33:50AM +0530, Anshuman Khandual wrote:
> >>> diff --git a/mm/filema
On Wed, Aug 30, 2017 at 07:19:30AM +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2017-08-29 at 13:27 +0200, Peter Zijlstra wrote:
> > mpe helped me out and explained that is the PWC hint to TBLIE.
> >
> > So, you set need_flush_all when you unhook pud/pmd/pte which you th
On Wed, Aug 30, 2017 at 10:33:50AM +0530, Anshuman Khandual wrote:
> diff --git a/mm/filemap.c b/mm/filemap.c
> index a497024..08f3042 100644
> --- a/mm/filemap.c
> +++ b/mm/filemap.c
> @@ -1181,6 +1181,18 @@ int __lock_page_killable(struct page *__page)
> int __lock_page_or_retry(struct page *pag
On Tue, Aug 29, 2017 at 03:18:25PM +0200, Laurent Dufour wrote:
> On 29/08/2017 14:04, Peter Zijlstra wrote:
> > On Tue, Aug 29, 2017 at 09:59:30AM +0200, Laurent Dufour wrote:
> >> On 27/08/2017 02:18, Kirill A. Shutemov wrote:
> >>>> +
> >&
On Tue, Aug 29, 2017 at 09:59:30AM +0200, Laurent Dufour wrote:
> On 27/08/2017 02:18, Kirill A. Shutemov wrote:
> >> +
> >> + if (unlikely(!vma->anon_vma))
> >> + goto unlock;
> >
> > It deserves a comment.
>
> You're right I'll add it in the next version.
> For the record, the root ca
On Tue, Aug 29, 2017 at 10:33:52AM +0200, Peter Zijlstra wrote:
> On Tue, Aug 29, 2017 at 07:14:37AM +1000, Benjamin Herrenschmidt wrote:
> > We'd have to audit archs closely. Things like the page walk cache
> > flushing on power etc...
>
> If you point me where to loo
On Tue, Aug 29, 2017 at 07:14:37AM +1000, Benjamin Herrenschmidt wrote:
> On Mon, 2017-08-28 at 11:37 +0200, Peter Zijlstra wrote:
> > > Doing all this job and just give up because we cannot allocate page tables
> > > looks very wasteful to me.
> > >
> > >
On Mon, Aug 28, 2017 at 03:35:11PM -0700, Andi Kleen wrote:
> Yes the whole thing is quite risky. Probably will need some
> kind of per architecture opt-in scheme?
See patch 19/20, that not enough for you?
On Sun, Aug 27, 2017 at 03:18:23AM +0300, Kirill A. Shutemov wrote:
> On Fri, Aug 18, 2017 at 12:05:13AM +0200, Laurent Dufour wrote:
> > + /*
> > +* Can't call vm_ops service has we don't know what they would do
> > +* with the VMA.
> > +* This include huge page from hugetlbfs.
> > +
On Mon, Jul 10, 2017 at 08:10:50AM -0500, Segher Boessenkool wrote:
> > PERF_BR_INT is triggered by instruction "int" .
> > PERF_BR_IRQ is triggered by interrupts, traps, faults (the ring 0,3
> > transition).
>
> So your "PERF_BR_INT" is a system call?
The "INT" thing has indeed been used as s
PPC folks, maddy, does this work for you guys?
On Thu, Apr 20, 2017 at 08:07:49PM +0800, Jin Yao wrote:
> It is often useful to know the branch types while analyzing branch
> data. For example, a call is very different from a conditional branch.
>
> Currently we have to look it up in binary whil
d earlier in the context switch path.
>
> Comment this so it's clear enough if anything changes on the scheduler
> or the powerpc sides. Remove the hwsync from _switch.
>
> This improves context switch performance by 2-3% on POWER8.
>
> Cc: Peter Zijlstra
> Signed-
On Thu, Jun 08, 2017 at 11:18:13PM +1000, Nicholas Piggin wrote:
> I guess I see your point... okay, will constrain the comment to powerpc
> context switch and primitives code. Any fundamental change to such
> scheduler barriers I guess would require at least a glance over arch
> switch code :)
Ju
On Thu, Jun 08, 2017 at 08:00:15PM +1000, Nicholas Piggin wrote:
> I have those, I just also would like one in the core scheduler's use
> of smp_mb__after_spinlock(), because it would be easy for core scheduler
> change to miss that quirk. Sure we can say that Peter and scheduler
> maintainers kno
On Thu, Jun 08, 2017 at 05:29:38PM +1000, Nicholas Piggin wrote:
> On Thu, 8 Jun 2017 08:54:00 +0200
> Peter Zijlstra wrote:
>
> > On Thu, Jun 08, 2017 at 10:32:44AM +1000, Nicholas Piggin wrote:
> > > On Wed, 07 Jun 2017 18:15:06 +0200
> > > Peter Zijlstra wro
On Fri, Apr 28, 2017 at 03:44:23PM +0200, Petr Mladek wrote:
> On Fri 2017-04-28 11:02:26, Peter Zijlstra wrote:
> > On Thu, Apr 27, 2017 at 03:38:19PM +0200, Petr Mladek wrote:
> > > Also we need to look for alternatives. There is a chance
> > > to create crashdump
On Thu, Apr 27, 2017 at 03:38:19PM +0200, Petr Mladek wrote:
> Also we need to look for alternatives. There is a chance
> to create crashdump and get the ftrace messages from it.
> Also this might be scenario when we might need to suggest
> the early_printk() patchset from Peter Zijls
On Wed, Apr 19, 2017 at 01:13:41PM -0400, Steven Rostedt wrote:
> On Thu, 21 Apr 2016 13:48:42 +0200
> Petr Mladek wrote:
>
> > printk() takes some locks and could not be used a safe way in NMI context.
>
> I just found a problem with this solution. It kills ftrace dumps from
> NMI context :-(
>
On Thu, Apr 13, 2017 at 09:26:51AM -0700, Paul E. McKenney wrote:
> ARCH_WEAK_RELEASE_ACQUIRE actually works both ways.
>
> To see this, imagine some strange alternate universe in which the Power
> hardware guys actually did decide to switch PPC to doing RCsc as you
> suggest. There would still
nimal fix of adding big endian definition of the bitfields
> to match the values that are already exported by the kernel on big endian.
> And it makes no change on little endian.
I think it is important to note that there are no current big-endian
users. So 'fixing' this will not break anybody and will ensure future
users (next patch) will work correctly.
Aside from that amendment,
Acked-by: Peter Zijlstra (Intel)
On Wed, Apr 12, 2017 at 10:39:47AM -0700, Paul E. McKenney wrote:
> The definition of smp_mb__after_unlock_lock() is currently smp_mb()
> for CONFIG_PPC and a no-op otherwise. It would be better to instead
> provide an architecture-selectable Kconfig option, and select the
> strength of smp_mb__af
On Wed, Apr 12, 2017 at 10:39:47AM -0700, Paul E. McKenney wrote:
> CONFIG_ARCH_WEAK_RELACQ Kconfig option.
Naming in the changelog and patch don't match.
> +config ARCH_WEAK_RELEASE_ACQUIRE
> + bool
> +
On Tue, Apr 11, 2017 at 04:11:21PM +0800, Jin, Yao wrote:
>
>
> On 4/11/2017 3:52 PM, Peter Zijlstra wrote:
> > This is still a completely inadequate changelog. I really will not
> > accept patches like this.
> >
> Hi,
>
> The changelog is added in the cover
On Tue, Apr 11, 2017 at 09:52:19AM +0200, Peter Zijlstra wrote:
> On Tue, Apr 11, 2017 at 06:56:30PM +0800, Jin Yao wrote:
> > @@ -960,6 +1006,11 @@ intel_pmu_lbr_filter(struct cpu_hw_events *cpuc)
> > cpuc->lbr_entries[i].from = 0;
> >
On Tue, Apr 11, 2017 at 06:56:30PM +0800, Jin Yao wrote:
> Perf already has support for disassembling the branch instruction
> and using the branch type for filtering. The patch just records
> the branch type in perf_branch_entry.
>
> Before recording, the patch converts the x86 branch classificat
On Fri, Apr 07, 2017 at 09:48:34AM -0700, Andi Kleen wrote:
> On Fri, Apr 07, 2017 at 05:20:31PM +0200, Peter Zijlstra wrote:
> > On Fri, Apr 07, 2017 at 06:47:43PM +0800, Jin Yao wrote:
> > > Perf already has support for disassembling the branch instruction
> > > an
On Fri, Apr 07, 2017 at 06:47:43PM +0800, Jin Yao wrote:
> Perf already has support for disassembling the branch instruction
> and using the branch type for filtering. The patch just records
> the branch type in perf_branch_entry.
>
> Before recording, the patch converts the x86 branch classificat
On Thu, Apr 06, 2017 at 10:31:46AM -0700, Linus Torvalds wrote:
> But maybe "monitor" is really cheap. I suspect it's microcoded,
> though, which implies "no".
On my IVB-EP (will also try on something newer):
MONITOR ~332 cycles
MWAIT ~224 cycles (C0, explicitly invalidated MONITOR)
So yes, ex
On Thu, Apr 06, 2017 at 10:31:46AM -0700, Linus Torvalds wrote:
> And we'd probably want to make it even more strict, in that soem mwait
> implementations might simply not be very good for short waits.
Yeah, we need to find something that works; assuming its beneficial at
all on modern chips.
> >
On Thu, Apr 06, 2017 at 08:16:19AM -0700, Linus Torvalds wrote:
> In theory x86 could use monitor/mwait for it too, in practice I think
> it tends to still be too high latency (because it was originally just
> designed for the idle loop). mwait got extended to actually be useful,
> but I'm not sur
On Wed, Mar 15, 2017 at 05:20:15PM +1100, Michael Ellerman wrote:
> > I see no implementation; so why are you poking at it.
>
> Maddy has posted an implementation of the kernel part for powerpc in
> patch 2 of this series, but maybe you're not on Cc?
I am not indeed. That and a completely inadeq
On Tue, Mar 14, 2017 at 02:31:51PM +0530, Madhavan Srinivasan wrote:
> >Huh? PPC hasn't yet implemented this? Then why are you fixing it?
>
> yes, PPC hasn't implemented this (until now).
until now where?
> And did not understand "Then why are you fixing it?"
I see no implementation; so why ar
On Mon, Mar 13, 2017 at 04:45:51PM +0530, Madhavan Srinivasan wrote:
> > - should you not have fixed this in the tool only? This patch
> >effectively breaks ABI on big-endian architectures.
>
> IIUC, we are the first BE user for this feature
> (Kindly correct me if I am wrong), so technically
On Tue, Mar 07, 2017 at 03:28:17PM +0530, Madhavan Srinivasan wrote:
>
>
> On Monday 06 March 2017 04:52 PM, Peter Zijlstra wrote:
> >On Mon, Mar 06, 2017 at 04:13:08PM +0530, Madhavan Srinivasan wrote:
> >>From: Sukadev Bhattiprolu
> >>
> >>perf_mem_da
On Mon, Mar 06, 2017 at 02:59:07PM +, David Laight wrote:
> From: Peter Zijlstra
> > Sent: 06 March 2017 11:22
> > To: Madhavan Srinivasan
> > Cc: Wang Nan; Alexander Shishkin; linux-ker...@vger.kernel.org; Arnaldo
> > Carvalho de Melo; Alexei
> > Starovoit
On Mon, Mar 06, 2017 at 04:13:08PM +0530, Madhavan Srinivasan wrote:
> From: Sukadev Bhattiprolu
>
> perf_mem_data_src is an union that is initialized via the ->val field
> and accessed via the bitmap fields. For this to work on big endian
> platforms, we also need a big-endian represenation of p
On Fri, Feb 03, 2017 at 01:59:34PM +0100, Mike Galbraith wrote:
> On Fri, 2017-02-03 at 09:53 +0100, Peter Zijlstra wrote:
> > On Fri, Feb 03, 2017 at 10:03:14AM +0530, Sachin Sant wrote:
>
> > > I ran few cycles of cpu hot(un)plug tests. In most cases it works except
> &
On Fri, Feb 03, 2017 at 10:03:14AM +0530, Sachin Sant wrote:
>
> > On 02-Feb-2017, at 9:25 PM, Peter Zijlstra wrote:
> >
> > On Tue, Jan 31, 2017 at 10:22:47AM -0700, Ross Zwisler wrote:
> >> On Tue, Jan 31, 2017 at 4:48 AM, Mike Galbraith wrote:
> >>>
On Tue, Jan 31, 2017 at 10:22:47AM -0700, Ross Zwisler wrote:
> On Tue, Jan 31, 2017 at 4:48 AM, Mike Galbraith wrote:
> > On Tue, 2017-01-31 at 16:30 +0530, Sachin Sant wrote:
Could some of you test this? It seems to cure things in my (very)
limited testing.
---
diff --git a/kernel/sched/core.
On Mon, Jan 16, 2017 at 02:34:43PM +, David Laight wrote:
> From: Anton Blanchard
> > Sent: 15 January 2017 21:36
> > I was debugging a hang on a ppc64le kernel built with clang, and it
> > looks to be undefined behaviour with pointer wrapping in the llist code.
> >
> > A test case is below. l
On Mon, Jan 16, 2017 at 10:42:29PM +1100, Anton Blanchard wrote:
> Hi Peter,
>
> > Last I checked I couldn't build a x86_64 kernel with llvm. So no, not
> > something I've ever ran into.
> >
> > Also, I would argue that this is broken in llvm, the kernel very much
> > relies on things like this a
On Mon, Jan 16, 2017 at 08:36:00AM +1100, Anton Blanchard wrote:
> Hi,
>
> I was debugging a hang on a ppc64le kernel built with clang, and it
> looks to be undefined behaviour with pointer wrapping in the llist code.
>
> A test case is below. llist_for_each_entry() does container_of() on a
> NUL
On Tue, Jan 03, 2017 at 06:11:20PM -0800, Christian Kujau wrote:
> Hi,
>
> booting v4.10-rc2 on this PowerPC G4 machine prints the following early
> on, but then continues to boot and the machine is running fine so far:
>
>
> BUG: key ef0ba7d0 not in .data!
> DEBUG_LOCKS_WARN_ON(1)
> --
On Tue, Dec 13, 2016 at 07:19:43PM +0100, Christophe Leroy wrote:
> +int mpc8xx_pmu_event_init(struct perf_event *event)
> +{
> + int type = event_type(event);
> +
> + switch (type) {
> + case PERF_8xx_ID_CPU_CYCLES:
> + case PERF_8xx_ID_ITLB_LOAD_MISS:
> + case PERF_8xx_ID_DTLB
On Tue, Dec 13, 2016 at 04:54:30PM -0600, Segher Boessenkool wrote:
> On Tue, Dec 13, 2016 at 09:39:55PM +0100, christophe leroy wrote:
> > Le 13/12/2016 à 20:15, Segher Boessenkool a écrit :
> > >On Tue, Dec 13, 2016 at 07:19:41PM +0100, Christophe Leroy wrote:
> > >>At exception prologs, once SRR
On Wed, Nov 16, 2016 at 12:29:44PM +0100, Christian Borntraeger wrote:
> On 11/16/2016 11:23 AM, Peter Zijlstra wrote:
> > On Wed, Nov 16, 2016 at 12:19:09PM +0800, Pan Xinhui wrote:
> >> Hi, Peter.
> >>I think we can avoid a function call in a simpler way. How a
On Wed, Nov 16, 2016 at 12:19:09PM +0800, Pan Xinhui wrote:
> Hi, Peter.
> I think we can avoid a function call in a simpler way. How about below
>
> static inline bool vcpu_is_preempted(int cpu)
> {
> /* only set in pv case*/
> if (pv_lock_ops.vcpu_is_preempted)
>
On Wed, Nov 02, 2016 at 05:08:33AM -0400, Pan Xinhui wrote:
> diff --git a/arch/x86/include/asm/paravirt_types.h
> b/arch/x86/include/asm/paravirt_types.h
> index 0f400c0..38c3bb7 100644
> --- a/arch/x86/include/asm/paravirt_types.h
> +++ b/arch/x86/include/asm/paravirt_types.h
> @@ -310,6 +310,8
On Mon, Oct 24, 2016 at 09:52:31AM +0200, Christian Borntraeger wrote:
> Peter, I will fixup the patch set (I forgot to remove the lowlatency
> in 2 places) and push it on my tree for linux-next. Lets see what happens.
> Would the tip tree be the right place if things work out ok?
I think so, you'
On Fri, Oct 21, 2016 at 01:58:53PM +0200, Christian Borntraeger wrote:
> Christian Borntraeger (5):
> processor.h: introduce cpu_relax_yield
> stop_machine: yield CPU during stop machine
> s390: make cpu_relax a barrier again
> Remove cpu_relax_lowlatency users
> remove cpu_relax_lowlaten
On Fri, Oct 21, 2016 at 01:58:55PM +0200, Christian Borntraeger wrote:
> stop_machine can take a very long time if the hypervisor does
> overcommitment for guest CPUs. When waiting for "the one", lets
> give up our CPU by using the new cpu_relax_yield.
This seems something that would apply to most
On Thu, Oct 20, 2016 at 05:27:45PM -0400, Pan Xinhui wrote:
>
> This patch set aims to fix lock holder preemption issues.
Thanks, this looks very good. I'll wait for ACKs from at least the KVM
people, since that was I think the most contentious patch.
On Sat, Oct 08, 2016 at 10:07:33PM +1100, Anton Blanchard wrote:
> Hi,
>
> I updated to mainline as of today and tried CPU hotplug via the ppc64_cpu
> tool:
http://lkml.kernel.org/r/1475922278-3306-1-git-send-email-wanpeng...@hotmail.com
On Thu, Sep 29, 2016 at 12:23:19PM +0200, Christian Borntraeger wrote:
> On 09/29/2016 12:10 PM, Peter Zijlstra wrote:
> > On Thu, Jul 21, 2016 at 07:45:10AM -0400, Pan Xinhui wrote:
> >> change from v2:
> >>no code change, fix typos, update some comments
> >
On Thu, Jul 21, 2016 at 07:45:10AM -0400, Pan Xinhui wrote:
> change from v2:
> no code change, fix typos, update some comments
>
> change from v1:
> a simplier definition of default vcpu_is_preempted
> skip mahcine type check on ppc, and add config. remove dedicated macro.
>
On Thu, Sep 08, 2016 at 09:28:18AM -0700, Vineet Gupta wrote:
> This came to light when implementing native 64-bit atomics for ARCv2.
>
> The atomic64 self-test code uses CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
> to check whether atomic64_dec_if_positive() is available.
> It seems it was needed w
On Tue, Sep 06, 2016 at 09:55:43AM +0530, Madhavan Srinivasan wrote:
>
>
> On Thursday 01 September 2016 12:56 PM, Peter Zijlstra wrote:
> >On Mon, Aug 29, 2016 at 02:30:46AM +0530, Madhavan Srinivasan wrote:
> >>It's a perennial request from hardware folks to be a
On Mon, Aug 29, 2016 at 02:30:46AM +0530, Madhavan Srinivasan wrote:
> It's a perennial request from hardware folks to be able to
> see the raw values of the pmu registers. Partly it's so that
> they can verify perf is doing what they want, and some
> of it is that they're interested in some of the
> Not sure what commit cb30711 "perf_event: Don't allow vmalloc() backed
> perf on powerpc" was trying to do with it either.
>
> Signed-off-by: Kim Phillips
> Cc: Peter Zijlstra
> Cc: Michael Ellerman
> ---
> init/Kconfig | 13 -
> 1 file chan
Sorry, found it in my inbox while clearing out backlog..
On Sun, Jul 03, 2016 at 11:31:58PM +0530, Madhavan Srinivasan wrote:
> When decoding the perf_regs mask in perf_output_sample_regs(),
> we loop through the mask using find_first_bit and find_next_bit functions.
> While the exisitng code wor
On Fri, Jul 15, 2016 at 01:52:48PM +, Topi Miettinen wrote:
> On 07/15/16 12:43, Peter Zijlstra wrote:
> > On Fri, Jul 15, 2016 at 01:35:47PM +0300, Topi Miettinen wrote:
> >> Hello,
> >>
> >> There are many basic ways to control processes, including cap
On Fri, Jul 15, 2016 at 01:35:47PM +0300, Topi Miettinen wrote:
> Hello,
>
> There are many basic ways to control processes, including capabilities,
> cgroups and resource limits. However, there are far fewer ways to find out
> useful values for the limits, except blind trial and error.
>
> This
On Thu, Jul 07, 2016 at 11:42:15AM +0200, Peter Zijlstra wrote:
> +static void update_steal_time_preempt(struct kvm_vcpu *vcpu)
> +{
> + struct kvm_steal_time *st;
> +
> + if (!(vcpu->arch.st.msr_val & KVM_MSR_ENABLED))
> + return;
> +
> + if
On Thu, Jul 07, 2016 at 06:27:26PM +0800, Wanpeng Li wrote:
> In addition, I see xen's vcpu_runstate_info::state is updated during
> schedule, so I think I can do this similarly through kvm preemption
> notifier. IIUC, xen hypervisor has VCPUOP_get_runstate_info hypercall
> implemention, so the des
On Thu, Jul 07, 2016 at 11:42:15AM +0200, Peter Zijlstra wrote:
> I suspect you want something like so; except this has holes in.
>
> We clear KVM_ST_PAD_PREEMPT before disabling preemption and we set it
> after enabling it, this means that if we get preempted in between, the
> v
On Thu, Jul 07, 2016 at 06:12:51PM +0800, Wanpeng Li wrote:
> Btw, do this in preemption
> notifier means that the vCPU is real preempted on host, however,
> depends on vmexit is different semantic I think.
Not sure; suppose the vcpu is about to reenter, eg, we're in
vcpu_enter_guest() but before
On Thu, Jul 07, 2016 at 04:48:05PM +0800, Wanpeng Li wrote:
> 2016-07-06 20:28 GMT+08:00 Paolo Bonzini :
> > Hmm, you're right. We can use bit 0 of struct kvm_steal_time's flags to
> > indicate that pad[0] is a "VCPU preempted" field; if pad[0] is 1, the
> > VCPU has been scheduled out since the l
On Wed, Jul 06, 2016 at 12:44:58PM +0200, Paolo Bonzini wrote:
> > Paolo, could you help out with an (x86) KVM interface for this?
>
> If it's just for spin loops, you can check if the version field in the
> steal time structure has changed.
That would require remembering the old value, no?
That
On Wed, Jul 06, 2016 at 09:47:18AM +0200, Juergen Gross wrote:
> On 06/07/16 08:52, Peter Zijlstra wrote:
> > Paolo, could you help out with an (x86) KVM interface for this?
>
> Xen support of this interface should be rather easy. Could you please
> Cc: xen-devel-requ...@lists
On Wed, Jul 06, 2016 at 02:46:34PM +0800, Wanpeng Li wrote:
> > SO it's easy for ppc to implement such interface. Note that yield_count is
> > set by powerVM/KVM.
> > and only pSeries can run a guest for now. :)
> >
> > I also review x86 related code, looks like we need add one hyer-call to get
> >
On Tue, Jun 28, 2016 at 10:43:07AM -0400, Pan Xinhui wrote:
> change fomr v1:
> a simplier definition of default vcpu_is_preempted
> skip mahcine type check on ppc, and add config. remove dedicated macro.
> add one patch to drop overload of rwsem_spin_on_owner and
> mutex_spin_on
601 - 700 of 1104 matches
Mail list logo
