On Wed, Sep 16, 2015 at 11:49:33PM +0800, Boqun Feng wrote:
> Unlike other atomic operation variants, cmpxchg{,64}_acquire and
> atomic{,64}_cmpxchg_acquire don't have acquire semantics if the cmp part
> fails, so we need to implement these using assembly.
I think that is actually expected and doc
On Wed, Sep 16, 2015 at 11:49:32PM +0800, Boqun Feng wrote:
> Implement xchg_relaxed and define atomic{,64}_xchg_* as xchg_relaxed,
> based on these _relaxed variants, release/acquire variants can be built.
>
> Note that xchg_relaxed and atomic_{,64}_xchg_relaxed are not compiler
> barriers.
Hmm,
On Mon, Sep 14, 2015 at 02:01:53PM +0200, Peter Zijlstra wrote:
> The scenario is:
>
> CPU0CPU1
>
> unlock(x)
> smp_store_release(&x->lock, 0);
>
> unlock(y)
>
On Mon, Sep 14, 2015 at 01:35:20PM +0200, Peter Zijlstra wrote:
>
> Sorry for being tardy, I had a wee spell of feeling horrible and then I
> procrastinated longer than I should have.
>
> On Fri, Sep 11, 2015 at 01:45:07PM +0100, Will Deacon wrote:
>
> > Peter, any t
Sorry for being tardy, I had a wee spell of feeling horrible and then I
procrastinated longer than I should have.
On Fri, Sep 11, 2015 at 01:45:07PM +0100, Will Deacon wrote:
> Peter, any thoughts? I'm not au fait with the x86 memory model, but what
> Paul's saying is worrying.
Right, so Paul i
nt to be read
> >
> > pmu->commit_txn() // Read/update all queuedcounters
> >
> > The ->commit_txn() also updates the event counts in the respective
> > perf_event objects. The perf subsystem can then directly get the
> > event c
On Thu, Aug 13, 2015 at 11:49:34PM -0700, Sukadev Bhattiprolu wrote:
I'm ever so sorry I keep going on about this, but..
> diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
> index d90893b..b18efe4 100644
> --- a/arch/powerpc/perf/core-book3s.c
> +++ b/arch/powerpc/pe
On Fri, Aug 28, 2015 at 10:16:02PM +0800, Boqun Feng wrote:
> On Fri, Aug 28, 2015 at 08:06:14PM +0800, Boqun Feng wrote:
> > Hi Peter,
> >
> > On Fri, Aug 28, 2015 at 12:48:54PM +0200, Peter Zijlstra wrote:
> > > On Fri, Aug 28, 2015 at 10:4
On Fri, Aug 28, 2015 at 10:48:16AM +0800, Boqun Feng wrote:
> Some architectures may have their special barriers for acquire, release
> and fence semantics, general memory barriers(smp_mb__*_atomic()) in
> __atomic_op_*() may be too strong, so arch_atomic_op_*() helpers are
> introduced for archite
On Fri, Aug 28, 2015 at 10:48:17AM +0800, Boqun Feng wrote:
> +/*
> + * Since {add,sub}_return_relaxed and xchg_relaxed are implemented with
> + * a "bne-" instruction at the end, so an isync is enough as a acquire
> barrier
> + * on the platform without lwsync.
> + */
> +#ifdef CONFIG_SMP
> +#def
On Thu, Aug 20, 2015 at 08:14:31PM +0800, Kevin Hao wrote:
> These are used to define a static_key_{true,false} array.
Yes but why...
there might have been some clue in the patches you didn't send me, but
since you didn't send them, I'm left wondering.
On Thu, Aug 20, 2015 at 08:14:29PM +0800, Kevin Hao wrote:
> The jump_label_init() run in a very early stage, even before the
> sched_init(). So there is no chance for concurrent access of the
> jump label table.
It also doesn't hurt to have it. Its better to be consistent and
conservative with lo
On Thu, Aug 13, 2015 at 01:04:28PM -0700, Sukadev Bhattiprolu wrote:
> | > | +static int perf_read_group(struct perf_event *event,
> | > | + u64 read_format, char __user *buf)
> | > | +{
> | > | + struct perf_event *leader = event->group_leader, *child;
> | >
On Tue, Aug 11, 2015 at 09:14:00PM -0700, Sukadev Bhattiprolu wrote:
> | +static void __perf_read_group_add(struct perf_event *leader, u64
> read_format, u64 *values)
> | {
> | + struct perf_event *sub;
> | + int n = 1; /* skip @nr */
>
> This n = 1 is to skip over the values[0] = 1 + nr_sib
o flip the loops in perf_read_group(), find attached two
patches that go on top of 1,2,4.
After this you can add the perf_event_read() return value (just fold
patches 6,8) after which you can do patch 10 (which has a broken
Subject fwiw).
Subject: perf: Add group reads to perf_event_read()
From: Pe
On Sun, Aug 02, 2015 at 05:11:04PM +0200, Andrey Konovalov wrote:
> Replace ACCESS_ONCE() macro in smp_store_release() and smp_load_acquire()
> with WRITE_ONCE() and READ_ONCE() on x86, arm, arm64, ia64, metag, mips,
> powerpc, s390, sparc and asm-generic since ACCESS_ONCE does not work
> reliably
On Wed, Jul 22, 2015 at 04:19:16PM -0700, Sukadev Bhattiprolu wrote:
> Peter Zijlstra [pet...@infradead.org] wrote:
> | I've not woken up yet, and not actually fully read the email, but can
> | you stuff the entire above chunk inside the IPI?
> |
> | I think you could th
> Signed-off-by: Sukadev Bhattiprolu
>
> Changelog[v3]
> Rather than move perf_event_read() into callers and then
> rename, just move the computations into a separate function
> (redesign to address comment from Peter Zijlstra).
>
On Tue, Jul 21, 2015 at 06:50:45PM -0700, Sukadev Bhattiprolu wrote:
> We are trying to use the following interface:
>
> start_txn(pmu, PERF_PMU_TXN_READ);
>
> perf_event_read(leader);
> list_for_each(sibling, &leader->sibling_list, group_entry)
> perf_event_read(s
On Tue, Jul 14, 2015 at 08:01:54PM -0700, Sukadev Bhattiprolu wrote:
> +/*
> + * Use the transaction interface to read the group of events in @leader.
> + * PMUs like the 24x7 counters in Power, can use this to queue the events
> + * in the ->read() operation and perform the actual read in ->commit
> Signed-off-by: Sukadev Bhattiprolu
>
> Changelog[v3]
> Rather than move perf_event_read() into callers and then
> rename, just move the computations into a separate function
> (redesign to address comment from Peter Zijlstra).
> ---
Changelog[] bits go here, belo
On Tue, Jul 14, 2015 at 08:01:50PM -0700, Sukadev Bhattiprolu wrote:
> +DEFINE_PER_CPU(int, nop_txn_flags);
> +
> +static int nop_txn_flags_get_and_clear(void)
> +{
> + int *flagsp;
> + int flags;
> +
> + flagsp = &get_cpu_var(nop_txn_flags);
> +
> + flags = *flagsp;
> + *f
On Tue, Jul 14, 2015 at 08:01:50PM -0700, Sukadev Bhattiprolu wrote:
> @@ -1604,6 +1613,12 @@ static void power_pmu_start_txn(struct pmu *pmu)
> static void power_pmu_cancel_txn(struct pmu *pmu)
> {
> struct cpu_hw_events *cpuhw = this_cpu_ptr(&cpu_hw_events);
> + int txn_flags;
> +
> +
On Wed, Jul 15, 2015 at 03:52:34PM +0300, Konstantin Khlebnikov wrote:
> On 15.07.2015 15:16, Eric Dumazet wrote:
> >On Wed, 2015-07-15 at 12:52 +0300, Konstantin Khlebnikov wrote:
> >>These functions check should_resched() before unlocking spinlock/bh-enable:
> >>preempt_count always non-zero => s
On Wed, 2015-06-10 at 15:13 -0500, Scott Wood wrote:
> What sort of "nesting nonsense" would we get on ppc32? I wasn't
> trying to say that the pseudo-NMIs didn't count -- I was pointing out
> that we don't even have that on ppc32.
Oh, I was not aware ppc32 did not have that.
> > # git grep n
On Wed, 2015-06-10 at 14:17 -0500, Scott Wood wrote:
> On Wed, 2015-06-10 at 13:41 +0200, Peter Zijlstra wrote:
> > Hi Mike, Ben,
> >
> > I just noticed:
> >
> > arch/powerpc/Kconfig: select HAVE_PERF_EVENTS_NMI if PPC64
> >
> > But can't ppc
Hi Mike, Ben,
I just noticed:
arch/powerpc/Kconfig: select HAVE_PERF_EVENTS_NMI if PPC64
But can't ppc32 have FSL_EMB perf?
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Thu, May 28, 2015 at 02:59:26PM +0530, Madhavan Srinivasan wrote:
> When a event also carries a event.unit file, having newline char
> will make perf userspace tool to print the event name in
> the next line when dumping counter data.
And changing the kernel will break the API (it includes a '\
we need to
> include this or we always get the non jump label fallback code.
>
> Fixes: 1bc9e47aa8e4 ("powerpc/jump_label: Use HAVE_JUMP_LABEL")
> Signed-off-by: Anton Blanchard
Acked-by: Peter Zijlstra (Intel)
___
Linuxppc-dev m
> We also need to add -DCC_HAVE_ASM_GOTO to KBUILD_AFLAGS.
>
> Signed-off-by: Anton Blanchard
Acked-by: Peter Zijlstra (Intel)
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
bels in assembly, it
> will still need to define a macro to create the __jump_table
> entries (see ARCH_STATIC_BRANCH in the powerpc asm/jump_label.h
> for an example).
>
> Signed-off-by: Anton Blanchard
Acked-by: Peter Zijlstra (Intel)
__
On Tue, Apr 07, 2015 at 05:34:59PM -0700, Sukadev Bhattiprolu wrote:
> @@ -1213,9 +1221,47 @@ static void update_event_count(struct perf_event
> *event, u64 now)
> static void h_24x7_event_read(struct perf_event *event)
> {
> u64 now;
> + struct h_24x7_hw *h24x7hw;
> + struct hv_24
u_disable for TXN_READ ?
That seems entirely unneeded in this case.
---
Subject: perf: Rename perf_event_read_{one,group}, perf_read_hw
In order to free up the perf_event_read_group() name:
s/perf_event_read_\(one\|group\)/perf_read_\1/g
s/perf_read_hw/__perf_read/g
Signed-off-by: Peter
On Tue, Apr 07, 2015 at 05:34:57PM -0700, Sukadev Bhattiprolu wrote:
> perf_event_read_value() is mostly computing the event count and enabled/
> running times. Move the perf_event_read() into caller and rename
> perf_event_read_value() to perf_event_compute_values().
>
> Changelog[v2]
> Exp
On Tue, Apr 07, 2015 at 05:34:55PM -0700, Sukadev Bhattiprolu wrote:
> diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
> index 2b62198..4dc3d70 100644
> --- a/include/linux/perf_event.h
> +++ b/include/linux/perf_event.h
> @@ -240,20 +240,27 @@ struct pmu {
>*
>
On Wed, Apr 08, 2015 at 12:32:01PM +0200, Brice Goglin wrote:
> Le 07/04/2015 21:41, Peter Zijlstra a écrit :
> > No, that's very much not the same. Even if it were dealing with hotplug
> > it would still assume the cpu to return to the same node.
> >
> > But mos
On Tue, Apr 07, 2015 at 10:14:10AM -0700, Nishanth Aravamudan wrote:
> > So I think (and ISTR having stated this before) that dynamic cpu<->node
> > maps are absolutely insane.
>
> Sorry if I wasn't involved at the time. I agree that it's a bit of a
> mess!
>
> > There is a ton of stuff that assu
On Mon, Apr 06, 2015 at 02:45:58PM -0700, Nishanth Aravamudan wrote:
> Hi Peter,
>
> As you are very aware, I think, power has some odd NUMA topologies (and
> changes to the those topologies) at run-time. In particular, we can see
> a topology at boot:
>
> Node 0: all Cpus
> Node 7: no cpus
>
>
On Thu, Apr 02, 2015 at 02:12:47PM +0200, Ingo Molnar wrote:
> Okay. I'll resurrect the fix with a hotplug_cpu__tick_pull() name -
> agreed?
Sure.
> > > Also, I improved the changelog (attached below), but decided
> > > against applying it until these questions are cleared - please use
> > > t
On Thu, Apr 02, 2015 at 12:42:27PM +0200, Ingo Molnar wrote:
> So why not use a suitable CPU_DOWN* notifier for this, instead of open
> coding it all into a random place in the hotplug machinery?
Because notifiers are crap? ;-) Its entirely impossible to figure out
what's happening to core code i
On Wed, Mar 25, 2015 at 10:57:05PM -0700, Sukadev Bhattiprolu wrote:
> Would something liks this work?
>
Sure, that looks fine.
Thanks.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Wed, Mar 04, 2015 at 12:35:08AM -0800, Sukadev Bhattiprolu wrote:
> +++ b/kernel/events/core.c
> @@ -3677,11 +3677,34 @@ u64 perf_event_read_value(struct perf_event *event,
> u64 *enabled, u64 *running,
> }
> EXPORT_SYMBOL_GPL(perf_event_read_value);
>
> +static int do_pmu_group_read(struct
On Wed, Mar 04, 2015 at 12:35:07AM -0800, Sukadev Bhattiprolu wrote:
> extern u64 perf_event_read_value(struct perf_event *event,
> - u64 *enabled, u64 *running);
> + u64 *enabled, u64 *running, int update);
>
I think someone recently s
ags indicate wheether the transaction is to add events to
> the PMU (PERF_PMU_TXN_ADD) or to read the events PERF_PMU_TXN_READ.
>
> Based on input from Peter Zijlstra.
>
> Signed-off-by: Sukadev Bhattiprolu
> ---
> arch/powerpc/perf/core-book3s.c | 15 ---
> a
On Fri, Feb 06, 2015 at 04:43:54PM -0600, Tom Huynh wrote:
> arch/powerpc/perf/e6500-events-list.h | 289
> ++
That's a lot of events to stuff in the kernel, would a userspace list
not be more convenient?
ISTR there being various discussions on providing support f
On Tue, Dec 30, 2014 at 01:54:07PM -0500, Pranith Kumar wrote:
> On Tue, Dec 30, 2014 at 1:50 PM, Peter Zijlstra wrote:
> > On Tue, Dec 30, 2014 at 12:46:22AM -0500, Pranith Kumar wrote:
> >> Isolate the SRCU functions and data structures within CONFIG_SRCU so that
> >&
On Tue, Dec 30, 2014 at 12:46:22AM -0500, Pranith Kumar wrote:
> Isolate the SRCU functions and data structures within CONFIG_SRCU so that
> there
> is a compile time failure if srcu is used when not enabled. This was decided
> to
> be better than waiting until link time for a failure to occur.
On Wed, Oct 01, 2014 at 11:06:27AM +0200, Jiri Olsa wrote:
> On Thu, Sep 25, 2014 at 07:25:20PM -0700, Sukadev Bhattiprolu wrote:
> > Jiri Olsa [jo...@redhat.com] wrote:
> > | On Wed, Sep 24, 2014 at 12:27:15PM -0700, Sukadev Bhattiprolu wrote:
> > | > From: Cody P Schafer
> > | >
> > | > Enable
What's with the threading all versions together? Please don't do that --
also don't post a new version just for this though.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Fri, Sep 05, 2014 at 04:01:35PM -0400, Peter Hurley wrote:
> > So does this patch depends on a patch that removes pre EV56 alpha
> > support? I'm all for removing that, but I need to see the patch merged
> > before we can do this.
>
> I'm working on that but Alpha's Kconfig is not quite straigh
On Fri, Sep 05, 2014 at 11:31:09AM -0700, Paul E. McKenney wrote:
> compiler: Allow 1- and 2-byte smp_load_acquire() and smp_store_release()
>
> CPUs without single-byte and double-byte loads and stores place some
> "interesting" requirements on concurrent code. For example (adapted
> from Peter
On Thu, Sep 04, 2014 at 03:50:24PM +0100, Aaron Tomlin wrote:
> Currently in the event of a stack overrun a call to schedule()
> does not check for this type of corruption. This corruption is
> often silent and can go unnoticed. However once the corrupted
> region is examined at a later stage, the
On Thu, Sep 04, 2014 at 03:50:23PM +0100, Aaron Tomlin wrote:
> @@ -537,8 +535,8 @@ void bad_page_fault(struct pt_regs *regs, unsigned long
> address, int sig)
> printk(KERN_ALERT "Faulting instruction address: 0x%08lx\n",
> regs->nip);
>
> - stackend = end_of_stack(curr
On Fri, Aug 15, 2014 at 12:26:09AM -0700, Sukadev Bhattiprolu wrote:
> include/linux/perf_event.h | 10 +
> kernel/events/core.c | 8 +
Those are patches 9 and 12 iirc, no objection to that.
I've not had time to actually think about the res
On Mon, Apr 28, 2014 at 02:31:29PM +0530, Madhavan Srinivasan wrote:
> +unsigned int fault_around_order = CONFIG_FAULT_AROUND_ORDER;
__read_mostly?
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Wed, Apr 09, 2014 at 07:02:02AM +0530, Madhavan Srinivasan wrote:
> On Friday 04 April 2014 09:48 PM, Dave Hansen wrote:
> > On 04/03/2014 11:27 PM, Madhavan Srinivasan wrote:
> >> This patch creates infrastructure to move the FAULT_AROUND_ORDER
> >> to arch/ using Kconfig. This will enable arch
On Thu, Mar 20, 2014 at 11:03:50AM +0530, Srikar Dronamraju wrote:
> > > Joy,.. let me look at that with ppc in mind.
> >
> > OK; so while pretty much all the comments from that patch are utter
> > nonsense (what was I thinking), I cannot actually find a real bug.
> >
> > But could you try the be
On Wed, Mar 19, 2014 at 04:47:05PM +0100, Peter Zijlstra wrote:
> > I reverted b0c29f79ecea0b6fbcefc999e70f2843ae8306db on top of v3.14-rc6 and
> > confirmed that
> > reverting the commit solved the problem.
>
> Joy,.. let me look at that with ppc in mind.
OK; so w
On Wed, Mar 19, 2014 at 08:56:19PM +0530, Srikar Dronamraju wrote:
> There are 332 tasks all stuck in futex_wait_queue_me().
> I am able to reproduce this consistently.
>
> Infact I can reproduce this if the java_constraint is either node, socket,
> system.
> However I am not able to reproduce if
On Tue, Mar 04, 2014 at 02:07:31PM -0700, Bjorn Helgaas wrote:
> This is just cleanup of a couple unused interfaces and (for sparc64) a
> supporting variable.
>
Thanks!
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org
t; Signed-off-by: Liu Ping Fan
> Signed-off-by: Aneesh Kumar K.V
Acked-by: Peter Zijlstra
> ---
>
> include/linux/mm.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index f28f46eade6a..8624583
On Tue, Feb 25, 2014 at 01:38:31PM -0800, Cody P Schafer wrote:
> On 02/25/2014 02:20 AM, Peter Zijlstra wrote:
> >On Tue, Feb 25, 2014 at 02:33:26PM +1100, Michael Ellerman wrote:
> >>On Fri, 2014-14-02 at 22:02:06 UTC, Cody P Schafer wrote:
> >>>Export the swevent
On Tue, Feb 25, 2014 at 02:33:26PM +1100, Michael Ellerman wrote:
> On Fri, 2014-14-02 at 22:02:06 UTC, Cody P Schafer wrote:
> > Export the swevent hrtimer helpers currently only used in events/core.c
> > to allow the addition of architecture specific sw-like pmus.
>
> Peter, Ingo, can we get you
) is ((p)-MAX_RT_PRIO) the above two definitions are
the same and we can simply remove the spufs one.
Fixes: 6b6350f155af ("sched: Expose some macros related to priority")
Reported-by: Fengguang Wu
Signed-off-by: Peter Zijlstra
---
arch/powerpc/platforms/cell/spufs/sched.c | 1 -
1 fi
On Mon, Feb 10, 2014 at 04:52:17PM +0100, Torsten Duwe wrote:
> Opinions, anyone?
Since the holder thing is a performance thing, not a correctness thing;
one thing you could do is something like:
static const int OWNER_HASH_SIZE = CONFIG_NR_CPUS * 4;
static const int OWNER_HASH_BITS = ilog2(OWNER
On Fri, Feb 07, 2014 at 06:08:45PM +0100, Torsten Duwe wrote:
> > static inline unsigned int xadd(unsigned int *v, unsigned int i)
> > {
> > int t, ret;
> >
> > __asm__ __volatile__ (
> > "1: lwarx %0, 0, %4\n"
> > " mr %1, %0\n"
> > " add %0, %3, %0\n"
> > " stwcx. %
On Fri, Feb 07, 2014 at 05:58:01PM +0100, Torsten Duwe wrote:
> +static __always_inline void arch_spin_lock(arch_spinlock_t *lock)
> {
> + register struct __raw_tickets old, tmp,
> + inc = { .tail = TICKET_LOCK_INC };
> +
> CLEAR_IO_SYNC;
> + __asm__ __volatile__(
> +"1:
On Fri, Feb 07, 2014 at 09:51:16AM -0600, Kumar Gala wrote:
>
> On Feb 7, 2014, at 3:02 AM, Torsten Duwe wrote:
>
> > On Thu, Feb 06, 2014 at 02:19:52PM -0600, Scott Wood wrote:
> >> On Thu, 2014-02-06 at 18:37 +0100, Torsten Duwe wrote:
> >>> On Thu, Feb
On Fri, Feb 07, 2014 at 04:18:47PM +0100, Peter Zijlstra wrote:
> void ticket_lock(tickets_t *lock)
> {
> tickets_t t;
>
> /*
>* Because @head is MSB, the direct increment wrap doesn't disturb
>* @tail.
>*/
>
On Fri, Feb 07, 2014 at 01:28:37PM +0100, Peter Zijlstra wrote:
> Anyway, you can do a version with lwarx/stwcx if you're looking get rid
> of lharx.
the below seems to compile into relatively ok asm. It can be done better
if you write the entire thing by hand though.
---
typedef uns
On Fri, Feb 07, 2014 at 05:11:26PM +0530, Preeti U Murthy wrote:
> But observe the idle state "snooze" on powerpc. The power that this idle
> state saves is through the lowering of the thread priority of the CPU.
> After it lowers the thread priority, it is done. It cannot
> "wait_for_interrupts".
On Fri, Feb 07, 2014 at 11:09:23AM +, Nicolas Pitre wrote:
> On Thu, 6 Feb 2014, Peter Zijlstra wrote:
> > tree, tree, what's in a word.
>
> Something you may plant on a patch of grass? "Merging" becomes a
> strange concept in that context though. :-)
On Fri, Feb 07, 2014 at 12:49:49PM +0100, Torsten Duwe wrote:
> On Fri, Feb 07, 2014 at 11:45:30AM +0100, Peter Zijlstra wrote:
> >
> > That might need to be lhz too, I'm confused on all the load variants.
>
> ;-)
>
> > > unlock:
> > > lhz
On Fri, Feb 07, 2014 at 11:31:39AM +0100, Peter Zijlstra wrote:
> Anyway, what might work is something like (please forgive my ppc asm, I
> can barely read the thing, I've never before attempted writing it):
>
> lock:
> 1:lharx %0, 0, &head
> mov %1, %
> So if you have ll/sc on the whole word concurrent with the half-word
> store, you can loose the half-word store like:
>
> lwarx &tickets
> ... sth &tail
> stwcd &tickets
>
>
> The stwcd will over-write the tail store.
Oh wait, that's stupid, it will invalidate the lock a
On Fri, Feb 07, 2014 at 10:02:48AM +0100, Torsten Duwe wrote:
> On Thu, Feb 06, 2014 at 02:19:52PM -0600, Scott Wood wrote:
> > On Thu, 2014-02-06 at 18:37 +0100, Torsten Duwe wrote:
> > > On Thu, Feb 06, 2014 at 05:38:37PM +0100, Peter Zijlstra wrote:
> >
> > >
On Thu, Feb 06, 2014 at 06:37:27PM +0100, Torsten Duwe wrote:
> On Thu, Feb 06, 2014 at 05:38:37PM +0100, Peter Zijlstra wrote:
> > On Thu, Feb 06, 2014 at 11:37:37AM +0100, Torsten Duwe wrote:
> > > x86 has them, MIPS has them, ARM has them, even ia64 has them:
> > >
On Thu, Feb 06, 2014 at 02:09:59PM +, Nicolas Pitre wrote:
> Hi Peter,
>
> Did you merge those patches in your tree?
tree, tree, what's in a word. Its in my patch stack yes. I should get
some of that into tip I suppose, been side-tracked a bit this week.
Sorry for the delay.
> If so, is it
On Thu, Feb 06, 2014 at 11:37:37AM +0100, Torsten Duwe wrote:
> x86 has them, MIPS has them, ARM has them, even ia64 has them:
> ticket locks. They reduce memory bus and cache pressure especially
> for contended spinlocks, increasing performance.
>
> This patch is a port of the x86 spin locks, mos
On Thu, Jan 30, 2014 at 06:28:52PM +0100, Daniel Lezcano wrote:
> Ok, I think the mess is coming from 'default_idle' which does not re-enable
> the local_irq but used from different places like amd_e400_idle and
> apm_cpu_idle.
>
> void default_idle(void)
> {
> trace_cpu_idle_rcuidle(1, sm
On Thu, Jan 30, 2014 at 08:41:16AM -0800, Joe Perches wrote:
> Perhaps you could use a newer version of patch
>
> GNU patch version 2.7 released
Yeah, I know about that, I'll wait until its common in all distros,
updating all machines I use by hand is just painful.
___
On Thu, Jan 30, 2014 at 11:03:31AM -0500, Nicolas Pitre wrote:
> > This is not a valid patch for PATCH(1). Please try again.
>
> Don't you use git? ;-)
Nah, git and me don't get along well.
> Here's a plain patch:
Thanks!
___
Linuxppc-dev mailing lis
On Wed, Jan 29, 2014 at 12:45:13PM -0500, Nicolas Pitre wrote:
> Integration of cpuidle with the scheduler requires that the idle loop be
> closely integrated with the scheduler proper. Moving cpu/idle.c into the
> sched directory will allow for a smoother integration, and eliminate a
> subdirector
On Wed, Jan 29, 2014 at 12:45:07PM -0500, Nicolas Pitre wrote:
> As everyone should know by now, we want to integrate the cpuidle
> governor with the scheduler for a more efficient idling of CPUs.
> In order to help the transition, this small patch series moves the
> existing interaction with cpuid
On Wed, Jan 29, 2014 at 03:14:40PM -0500, Nicolas Pitre wrote:
> Looking into some cpuidle drivers for x86 I found at least one that
> doesn't respect this convention. Damn.
Which one? We should probably fix it :-)
___
Linuxppc-dev mailing list
Linuxpp
On Mon, Jan 27, 2014 at 05:21:10PM +, Russell King - ARM Linux wrote:
> A reviewed-by tag on its own doesn't mean much, as it could mean that
> you've just glanced over the code and decided "yea, it looks okay", or
> it could mean that you've spent all day verifying that the code change
> is in
On Mon, Jan 27, 2014 at 01:08:15AM -0500, Nicolas Pitre wrote:
> As everyone should know by now, we want to integrate the cpuidle
> governor with the scheduler for a more efficient idling of CPUs.
> In order to help the transition, this small patch series moves the
> existing interaction with cpuid
On Wed, Dec 11, 2013 at 07:52:51AM +1100, Benjamin Herrenschmidt wrote:
> On Tue, 2013-12-10 at 15:40 +0100, Alexander Graf wrote:
> > On 10.12.2013, at 15:21, Aneesh Kumar K.V
> > wrote:
> >
> > > From: "Aneesh Kumar K.V"
> > >
> > > We already checked need_resched. So we can call schedule di
On Thu, Nov 07, 2013 at 11:17:41AM +, Will Deacon wrote:
> Hi Peter,
>
> Couple of minor fixes on the arm64 side...
>
> On Wed, Nov 06, 2013 at 01:57:36PM +, Peter Zijlstra wrote:
> > --- a/arch/arm64/include/asm/barrier.h
> > +++ b/arch/arm64/include/asm/bar
On Wed, Nov 06, 2013 at 10:48:48AM -0800, Paul E. McKenney wrote:
> A few nits on Documentation/memory-barriers.txt and some pointless
> comments elsewhere. With the suggested Documentation/memory-barriers.txt
> fixes:
>
> Reviewed-by: Paul E. McKenney
Thanks, I think I'll cut the thing into a
xed a silly mistake in the return type definition for most
smp_load_acquire() implementions: typeof(p) vs typeof(*p).
---
Subject: arch: Introduce smp_load_acquire(), smp_store_release()
From: Peter Zijlstra
Date: Mon, 4 Nov 2013 20:18:11 +0100
A number of situations currently require the heavyweight smp_mb(),
Subject: arch: Introduce smp_load_acquire(), smp_store_release()
From: Peter Zijlstra
Date: Mon, 4 Nov 2013 20:18:11 +0100
A number of situations currently require the heavyweight smp_mb(),
even though there is no need to order prior stores against later
loads. Many architectures have much
On Tue, Nov 05, 2013 at 02:05:48PM +, Will Deacon wrote:
> > > +
> > > +#define smp_store_release(p, v)
> > > \
> > > +do { \
> > > + smp_mb();
On Mon, Nov 04, 2013 at 08:11:27PM +0100, Peter Zijlstra wrote:
> +#define smp_load_acquire(p, v)
> \
I R idiot!! :-)
---
arch/alpha/include/asm/barrier.h | 13 +++
arch/arc/include/asm/barrier.h| 13 +++
ar
On Mon, Nov 04, 2013 at 08:27:32AM -0800, Paul E. McKenney wrote:
> All this is leading me to suggest the following shortenings of names:
>
> smp_load_with_acquire_semantics() -> smp_load_acquire()
>
> smp_store_with_release_semantics() -> smp_store_release()
>
> But names aside, the
On Mon, Nov 04, 2013 at 08:27:32AM -0800, Paul E. McKenney wrote:
> >
> >
> > /*
> > * One important detail is that the kbuf part and the kbuf_writer() are
> > * strictly per cpu and we can thus rely on program order for those.
> > *
> > * Only the userspace consumer can possibly run on anoth
On Mon, Nov 04, 2013 at 02:51:00AM -0800, Paul E. McKenney wrote:
> OK, something like this for the definitions (though PowerPC might want
> to locally abstract the lwsync expansion):
>
> #define smp_store_with_release_semantics(p, v) /* x86, s390, etc. */ \
> do { \
> ba
On Sat, Nov 02, 2013 at 08:20:48AM -0700, Paul E. McKenney wrote:
> On Fri, Nov 01, 2013 at 11:30:17AM +0100, Peter Zijlstra wrote:
> > Furthermore there's a gazillion parallel userspace programs.
>
> Most of which have very unaggressive concurrency designs.
pthread_mutex_t
On Sun, Nov 03, 2013 at 10:08:14AM -0800, Linus Torvalds wrote:
> On Sun, Nov 3, 2013 at 7:17 AM, Peter Zijlstra wrote:
> > On Sun, Nov 03, 2013 at 06:40:17AM -0800, Paul E. McKenney wrote:
> >> If there was an smp_tmb(), I would likely use it in rcu_assign_pointer().
> >
r..
X86 (!OOSTORE), SPARC have native TSO memory models and smp_tmb()
reduces to barrier().
PPC can use lwsync instead of sync
For the other archs, have smp_tmb map to smp_mb, as the stronger barrier
is always correct but possibly suboptimal.
Suggested-by: Paul McKenney
Not-Signed-off-by: Peter
801 - 900 of 1104 matches
Mail list logo
