On Thu, 2012-09-13 at 16:19 +0900, Namhyung Kim wrote:
> When --cumulate option is given, it'll be shown like this:
>
>$ perf report --cumulate
>(...)
>+ 93.63% abc libc-2.15.so[.] __libc_start_main
>+ 93.35% abc abc [.] main
>+ 93.35% abc abc
On Mon, 2012-10-29 at 21:39 +0100, Stephane Eranian wrote:
> But I think the right mechanism would be one where you
> can add events at boot time based on CPU model. It could be used
> to add the common events as well in the common part of the init
> code.
mlin once posted something like that, it
On Tue, 2012-10-30 at 11:27 +0530, Raghavendra K T wrote:
> Okay, now IIUC, usage of *any* global measure is bad?
Yep, people like to carve up their machines, esp. now that they're
somewhat bigger than they used to be. This can result in very asymmetric
loads, no global measure can ever deal with
On Tue, 2012-10-30 at 15:59 +0900, Namhyung Kim wrote:
> Yes, the callchain part needs to be improved. Peter's idea indeed looks
> good to me too.
FWIW, I think this is exactly what sysprof does, except that tool isn't
usable for other reasons.. You might want to look at it though.
--
To unsubsc
On Tue, 2012-10-30 at 09:18 +0100, Ingo Molnar wrote:
> > > The optimal way, I guess, would be to have some cache file
> > > with the results of such feature tests, that would be created
> > > and then used till the build fails using its findings, which
> > > would trigger a new feature check ro
On Tue, 2012-10-30 at 23:40 -0700, Sukadev Bhattiprolu wrote:
> So instead of the names I came up with in this patch,
> stalled-cycles-fixed-point
> we could use the name used in the CPU spec - 'cmplu_stall_fxu' in the arch
> specific code ?
You could, but I would advise against it. Human readab
On Tue, 2012-10-30 at 20:45 -0700, Paul E. McKenney wrote:
> This commit therefore adds the ability
> for selected CPUs ("rcu_nocbs=" boot parameter) to have their
> callbacks
> offloaded to kthreads, inspired by Joe Korty's and Jim Houston's JRCU.
> If the "rcu_nocb_poll" boot parameter is also sp
On Sat, Aug 24, 2013 at 03:09:38AM -0700, Paul Turner wrote:
> On Mon, Aug 19, 2013 at 9:01 AM, Peter Zijlstra wrote:
> > + struct sg_lb_stats *this, *busiest;
>
> "this" is a little confusing to read; mainly because elsewhere we've
> tied this to "t
On Sat, Aug 24, 2013 at 03:15:57AM -0700, Paul Turner wrote:
> > +static inline void init_sd_lb_stats(struct sd_lb_stats *sds)
> > +{
> > + /*
> > +* struct sd_lb_stats {
> > +* struct sched_group * busiest; // 0
> > 8
> > +* str
On Sat, Aug 24, 2013 at 03:33:59AM -0700, Paul Turner wrote:
> On Mon, Aug 19, 2013 at 9:01 AM, Peter Zijlstra wrote:
> > +++ b/kernel/sched/fair.c
> > @@ -4977,7 +4977,7 @@ static struct rq *find_busiest_queue(str
> > unsigned long busiest_load = 0, busiest_powe
On Sat, Aug 24, 2013 at 03:45:57AM -0700, Paul Turner wrote:
> > @@ -5157,6 +5158,13 @@ cpu_attach_domain(struct sched_domain *s
> > tmp->parent = parent->parent;
> > if (parent->parent)
> > parent->parent->child = tmp;
On Mon, Aug 26, 2013 at 11:31:11AM +0200, Stephane Eranian wrote:
> On Fri, Aug 23, 2013 at 9:51 PM, Vince Weaver
> wrote:
> >
> > On Mon, 8 Jul 2013, Vince Weaver wrote:
> >
> > If PERF_SAMPLE_BRANCH_STACK is enabled then samples are returned
> > with the format { u64 from, to, flags } but the f
OK, here's one that actually works and doesn't have magical crashes.
---
Subject: mm, sched, numa: Create a per-task MPOL_INTERLEAVE policy
From: Peter Zijlstra
Date: Mon Jul 22 10:42:38 CEST 2013
For those tasks belonging to groups that span nodes -- for whatever
reason --
On Mon, Aug 26, 2013 at 06:10:27PM +0200, Peter Zijlstra wrote:
> + if (pol == new) {
> + /*
> + * XXX 'borrowed' from do_set_mempolicy()
This should probably also say something like:
/*
* This is safe without holding mm->mmap_sem for show_
by: Adrian Hunter
> >
> > Any comments?
>
> Ok with me, Peter?
Yeah I suppose so.. I don't really like it and I've made a start at
looking at the problem twice now but never got anywhere, so sure lets go
with this.
Acked-by: Peter Zijlstra
--
To unsubscribe from
On Mon, Aug 26, 2013 at 10:37:22PM -0400, Richard Guy Briggs wrote:
> On Fri, Aug 23, 2013 at 08:36:21AM +0200, Peter Zijlstra wrote:
> > Except that's not the case, with namespaces there's a clear hierarchy
> > and the task_struct::pid is the one true value aka. root
On Mon, Aug 26, 2013 at 03:03:04PM -0400, Steven Rostedt wrote:
> > Is there some path through sys_perf_open_event that might be
> > missing a capability check perhaps ?
> >
>
> That's a question for Ingo, Peter or Jiri.
Its not something I've looked at recently, git blames Jiri and fweisbec
for
On Tue, Aug 27, 2013 at 09:14:36AM -0400, Steven Rostedt wrote:
> I just had this conversation with Paul McKenney. Should there be a
> smp_mb_after_spin_unlock()?
Depends on the benefits I suppose :-) Oleg and Linus did recently add
smp_mb__before_spinlock();
> Although we blew it off as adding
On Tue, Aug 27, 2013 at 02:35:11PM -0700, Eric W. Biederman wrote:
> Peter Zijlstra writes:
>
> > On Mon, Aug 26, 2013 at 10:37:22PM -0400, Richard Guy Briggs wrote:
> >> On Fri, Aug 23, 2013 at 08:36:21AM +0200, Peter Zijlstra wrote:
> >> > Except that's n
On Tue, Aug 27, 2013 at 06:21:29PM -0700, Paul E. McKenney wrote:
> On Tue, Aug 27, 2013 at 03:53:10PM +0200, Peter Zijlstra wrote:
> > On Tue, Aug 27, 2013 at 09:14:36AM -0400, Steven Rostedt wrote:
> >
> > > I just had this conversation with Paul McK
Subject: sched, fair: Reduce local_group logic
From: Peter Zijlstra
Date: Wed Aug 28 10:32:32 CEST 2013
Try and reduce the local_group logic by pulling most of it into
update_sd_lb_stats.
We could completely get rid of the local_group variable, but that
results in two calls to
# ls -la defconfig-build/kernel/sched/fair.o*
-rw-r--r-- 1 root root 760688 Aug 28 10:53 defconfig-build/kernel/sched/fair.o
-rw-r--r-- 1 root root 758160 Aug 28 10:36
defconfig-build/kernel/sched/fair.o.orig
---
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -4553,9 +4553,9 @@ static in
On Wed, Aug 28, 2013 at 10:55:42AM +0200, Peter Zijlstra wrote:
> @@ -4690,19 +4694,20 @@ static inline void update_sd_lb_stats(st
>* heaviest group when it is already under-utilized (possible
>* with a large weight task outweighs the tasks on t
On Wed, Aug 28, 2013 at 11:18:14AM +0200, Ingo Molnar wrote:
> But ideally THP should detect cases where a hugepage is heavily used from
> multiple nodes and un-HP the page in question. Or not turn it into a
> hugepage in the first place. (We actually have a memory access pattern
> sampling faci
Subject: sched, fair: Fix group power_orig computation
From: Peter Zijlstra
Date: Wed Aug 28 11:44:39 CEST 2013
When looking at the code I noticed we don't actually compute
sgp->power_orig correctly for groups, fix that.
Currently the only consumer of that value is fix_small_capacity
Subject: sched, fair: Rework and comment the group_capacity code
From: Peter Zijlstra
Date: Wed Aug 28 11:50:34 CEST 2013
Pull out the group_capacity computation so that we can more clearly
comment its issues.
Signed-off-by: Peter Zijlstra
---
kernel/sched/fair.c | 32
Subject: sched, fair: Fix the group_capacity computation
From: Peter Zijlstra
Date: Wed Aug 28 12:40:38 CEST 2013
Do away with 'phantom' cores due to N*frac(smt_power) >= 1 by limiting
the capacity to the actual number of cores.
The assumption of 1 < smt_power < 2 is an
On Wed, Aug 28, 2013 at 08:59:57AM -0400, Steven Rostedt wrote:
> On Wed, 28 Aug 2013 10:19:37 +0200
> Peter Zijlstra wrote:
>
>
> > > An unlock followed by a lock needs to act like a full barrier, but there
> > > is no requirement that a lock or unlock taken se
On Wed, Aug 28, 2013 at 09:15:30AM -0400, Steven Rostedt wrote:
> Are you for the smp_mb__after_spin_unlock() ?
Sure, if the performance gains of having it out-weight the added
complexity of having it :-)
Nice non answer methinks, no? Muwhaha. To me having one more or less
'conditional' full mb p
On Fri, Aug 02, 2013 at 06:47:15PM +0200, Peter Zijlstra wrote:
> Subject: sched, numa: Use {cpu, pid} to create task groups for shared faults
> From: Peter Zijlstra
> Date: Tue Jul 30 10:40:20 CEST 2013
>
> A very simple/straight forward shared fault task grouping
> implement
On Wed, Aug 28, 2013 at 07:48:14PM +, Christoph Lameter wrote:
> Transformations done to __get_cpu_var()
>
>
> 1. Determine the address of the percpu instance of the current processor.
>
> DEFINE_PER_CPU(int, y);
> int *x = &__get_cpu_var(y);
>
> Converts to
>
> int *
On Thu, Aug 29, 2013 at 10:28:29AM +0100, Mel Gorman wrote:
> On Fri, Aug 23, 2013 at 08:15:46PM +0200, Peter Zijlstra wrote:
> > On Fri, Aug 23, 2013 at 03:03:32PM +0200, Peter Zijlstra wrote:
> > > So I think this patch is broken (still).
>
> I am assuming the lack of
On Thu, Aug 29, 2013 at 11:43:42AM +0200, Peter Zijlstra wrote:
> > diff --git a/mm/mempolicy.c b/mm/mempolicy.c
> > index 7431001..ae880c3 100644
> > --- a/mm/mempolicy.c
> > +++ b/mm/mempolicy.c
> > @@ -1755,22 +1755,24 @@ unsigned slab_node(void)
> > }
>
On Thu, Aug 29, 2013 at 11:56:57AM +0100, Mel Gorman wrote:
> > I thought it was, we crashed somewhere suspiciously close, but no. You
> > need shared mpols for this to actually trigger and the NUMA stuff
> > doesn't use that.
> >
>
> Ah, so this is a red herring?
Yeah, but I still think its an
On Tue, Oct 01, 2013 at 04:09:40PM +0200, Oleg Nesterov wrote:
> But somehow I didn't realize that ___wait_cond_timeout() can be used
> as is, so the simple patch below should work?
Yeah, should work.. But how often do people use timeout=0? Should we
really care about that case to the effect of ad
On Tue, Oct 01, 2013 at 07:45:37AM -0700, Paul E. McKenney wrote:
> If you don't have cpuhp_seq, you need some other way to avoid
> counter overflow. Which might be provided by limited number of
> tasks, or, on 64-bit systems, 64-bit counters.
How so? PID space is basically limited to 30 bits, so
On Tue, Oct 01, 2013 at 04:05:27PM +0200, Frederic Weisbecker wrote:
> struct cpu_idletime {
>nr_iowait,
>seqlock,
>idle_start,
>idle_time,
>iowait_time,
> } __cacheline_aligned_in_smp;
>
> DEFINE_PER_CPU(struct cpu_idletime, cpu_idletime);
>
> io_
So what's wrong with something like:
struct cpu_idletime {
seqlock_t seqlock;
unsigned long nr_iowait;
u64 start;
u64 idle_time,
u64 iowait_time,
} __cacheline_aligned_in_smp;
DEFINE_PER_CPU(struct cpu_idletime, cpu_idletime);
void io_schedule(void)
{
On Tue, Oct 01, 2013 at 06:47:10PM +0200, Frederic Weisbecker wrote:
> Yeah thinking more about it, the preempt disable was probably not
> necessary. Now that's trading 2 atomics + 1 Lock/Unlock with 2 Lock/Unlock.
It trades the current 2 atomics for 2 LOCK/UNLOCK. And on x86_64 that's
2 atomics.
On Tue, Oct 01, 2013 at 07:01:37PM +0200, Oleg Nesterov wrote:
> This patch moves the signal-pending checks and part of DEFINE_WAIT's
> code into the new helper: prepare_to_wait_event().
>
> Yes, sure, prepare_to_wait_event() becomes a little bit slower than
> prepare_to_wait/prepare_to_wait_exclu
On Tue, Oct 01, 2013 at 10:41:15PM +0530, Srivatsa S. Bhat wrote:
> However, as Oleg said, its definitely worth considering whether this proposed
> change in semantics is going to hurt us in the future. CPU_POST_DEAD has
> certainly
> proved to be very useful in certain challenging situations (com
On Tue, Oct 01, 2013 at 07:33:37PM +0200, Oleg Nesterov wrote:
> > > if (___wait_is_interruptible(state) && intr) {
> > > \
> > > __ret = intr;
> > > \
>
> Since typeof(__ret) == typeof(intr) gcc can (likely)
On Tue, Oct 01, 2013 at 07:45:08PM +0200, Oleg Nesterov wrote:
> On 10/01, Peter Zijlstra wrote:
> >
> > On Tue, Oct 01, 2013 at 10:41:15PM +0530, Srivatsa S. Bhat wrote:
> > > However, as Oleg said, its definitely worth considering whether this
> > > proposed
&
On Mon, Sep 30, 2013 at 01:29:12PM -0700, Andi Kleen wrote:
> From: Andi Kleen
>
> __perf_event__output_id_sample looks at data->type to decide
> what to output.
>
> A lot of of the custom output functions, for example perf_log_throttle
> start with perf_event_header__init_id, which only initial
On Tue, Oct 01, 2013 at 08:07:50PM +0200, Oleg Nesterov wrote:
> > > But note that you do not strictly need this change. Just kill
> > > cpuhp_waitcount,
> > > then we can change cpu_hotplug_begin/end to use xxx_enter/exit we discuss
> > > in
> > > another thread, this should likely "join" all sy
Reduce macro complexity by using the new ___wait_event() helper.
No change in behaviour, identical generated code.
Reviewed-by: Oleg Nesterov
Signed-off-by: Peter Zijlstra
---
include/linux/tty.h | 21 +
include/linux/wait.h | 192 +++
2
e lot
without also changing generated code.
Reviewed-by: Oleg Nesterov
Signed-off-by: Peter Zijlstra
---
include/linux/wait.h | 36
1 file changed, 36 insertions(+)
--- a/include/linux/wait.h
+++ b/include/linux/wait.h
@@ -187,6 +187,42 @@ wait_queue_h
Purely a preparatory patch; it changes the control flow to match what
will soon be generated by generic code so that that patch can be a
unity transform.
Reviewed-by: Oleg Nesterov
Signed-off-by: Peter Zijlstra
---
include/linux/wait.h |9 +
1 file changed, 5 insertions(+), 4
Change all __wait_event*() implementations to match the corresponding
wait_event*() signature for convenience.
In particular this does away with the weird 'ret' logic. Since there
are __wait_event*() users this requires we update them too.
Reviewed-by: Oleg Nesterov
Signed-off
edule();
Change them all into the latter form.
Reviewed-by: Oleg Nesterov
Signed-off-by: Peter Zijlstra
---
include/linux/tty.h | 13 ++---
include/linux/wait.h | 35 ---
2 files changed, 22 insertions(+), 26 deletions(-)
--- a/include/linux/tty.h
+++ b/in
Reduce macro complexity by using the new ___wait_event() helper.
No change in behaviour, identical generated code.
Reviewed-by: Oleg Nesterov
Signed-off-by: Peter Zijlstra
---
include/linux/tty.h | 21 +
include/linux/wait.h | 192 +++
2
g the condition (as suggested by Oleg), this
avoids double evaluation of 'condition' which could be quite big.
Reviewed-by: Oleg Nesterov
Signed-off-by: Peter Zijlstra
---
include/linux/wait.h | 24 +++-
1 file changed, 11 insertions(+), 13 deletions(-)
--- a/i
Reduce macro complexity by using the new ___wait_event() helper.
No change in behaviour, identical generated code.
Reviewed-by: Oleg Nesterov
Signed-off-by: Peter Zijlstra
---
include/linux/tty.h | 21 +
include/linux/wait.h | 192 +++
2
While poking at the cpu hotplug implementation I had a desire to use
wait_event() with schedule_preempt_disabled() and found the ridiculous
amount of duplication in linux/wait.h.
These patches cure all the bloat and inconsistencies of these macros
that me and others noticed, while also making it '
Reduce macro complexity by using the new ___wait_event() helper.
No change in behaviour, identical generated code.
Reviewed-by: Oleg Nesterov
Signed-off-by: Peter Zijlstra
---
include/linux/tty.h | 21 +
include/linux/wait.h | 192 +++
2
Reduce macro complexity by using the new ___wait_event() helper.
No change in behaviour, identical generated code.
Reviewed-by: Oleg Nesterov
Signed-off-by: Peter Zijlstra
---
--- a/include/linux/wait.h
+++ b/include/linux/wait.h
@@ -582,22 +582,7 @@ do
Reduce macro complexity by using the new ___wait_event() helper.
No change in behaviour, identical generated code.
Reviewed-by: Oleg Nesterov
Signed-off-by: Peter Zijlstra
---
include/linux/tty.h | 21 +
include/linux/wait.h | 192 +++
2
Reduce macro complexity by using the new ___wait_event() helper.
No change in behaviour, identical generated code.
Reviewed-by: Oleg Nesterov
Signed-off-by: Peter Zijlstra
---
include/linux/wait.h | 13 ++---
1 file changed, 2 insertions(+), 11 deletions(-)
--- a/include/linux
Reduce macro complexity by using the new ___wait_event() helper.
No change in behaviour, identical generated code.
Reviewed-by: Oleg Nesterov
Signed-off-by: Peter Zijlstra
---
include/linux/tty.h | 21 +
include/linux/wait.h | 192 +++
2
Reduce macro complexity by using the new ___wait_event() helper.
No change in behaviour, identical generated code.
Reviewed-by: Oleg Nesterov
Signed-off-by: Peter Zijlstra
---
include/linux/tty.h | 21 +
include/linux/wait.h | 192 +++
2
Reduce macro complexity by using the new ___wait_event() helper.
No change in behaviour, identical generated code.
Reviewed-by: Oleg Nesterov
Signed-off-by: Peter Zijlstra
---
include/linux/tty.h | 21 +
include/linux/wait.h | 192 +++
2
While not a whole-sale replacement like the others we can still reduce
the size of __wait_event_hrtimeout() considerably by noting that the
actual core of __wait_event_hrtimeout() is identical to what
___wait_event() generates.
Reviewed-by: Oleg Nesterov
Signed-off-by: Peter Zijlstra
On Tue, Oct 01, 2013 at 10:11:56PM +0300, Adrian Hunter wrote:
> Hi
>
> It does not seem possible to use set-output between
> task contexts of different types (e.g. a software event
> to a hardware event)
>
> If you look at perf_event_set_output():
>
> /*
>* If its not a pe
On Tue, Oct 01, 2013 at 01:22:58PM +0200, Stephane Eranian wrote:
> > So the problem is that we don't have a user visible address space
> > identifier; with CLONE_THREAD we have the thread group id that acts
> > like this. But for bare CLONE_VM usage there's nothing afaik.
>
>
> From the tool's p
On Wed, Oct 02, 2013 at 12:29:56PM +0200, Frederic Weisbecker wrote:
> On Wed, Oct 02, 2013 at 12:03:50PM +0200, Peter Zijlstra wrote:
> > On Tue, Oct 01, 2013 at 10:11:56PM +0300, Adrian Hunter wrote:
> > > Hi
> > >
> > > It does not seem possible to use set-o
On Tue, Oct 01, 2013 at 02:10:30AM -0700, tip-bot for Borislav Petkov wrote:
> Commit-ID: a17bce4d1dce8f3cf714bc2e5d8e4bac009dc077
> Gitweb: http://git.kernel.org/tip/a17bce4d1dce8f3cf714bc2e5d8e4bac009dc077
> Author: Borislav Petkov
> AuthorDate: Mon, 30 Sep 2013 11:56:24 +0200
> Committ
On Wed, Oct 02, 2013 at 01:23:16PM +0200, Peter Zijlstra wrote:
> So the only thing I can come up with is something like the below;
> supposedly the sha hash mixing a boot time random seed and the mm
> pointer is enough to avoid it being a data leak.
That is, right until it becomes fe
On Wed, Oct 02, 2013 at 01:52:35PM +0200, Peter Zijlstra wrote:
> On Tue, Oct 01, 2013 at 02:10:30AM -0700, tip-bot for Borislav Petkov wrote:
> > Commit-ID: a17bce4d1dce8f3cf714bc2e5d8e4bac009dc077
> > Gitweb:
> > http://git.kernel.org/tip/a17bce4d1dce8f3cf714bc2e5d8e4b
On Wed, Oct 02, 2013 at 02:13:56PM +0200, Oleg Nesterov wrote:
> On 10/02, Peter Zijlstra wrote:
> > And given the construct; I'm not entirely sure you can do away with the
> > sync_sched() in between. While its clear to me you can merge the two
> > into one; leaving it
On Wed, Oct 02, 2013 at 02:29:01PM +0200, Ingo Molnar wrote:
>
> Btw., this does not seem to be working very well when the perf context is
> inherited:
https://lkml.org/lkml/2011/7/21/124
Never figured that one out :-(
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" i
On Wed, Oct 02, 2013 at 02:39:53PM +0200, Ingo Molnar wrote:
> - then there are timing attacks, and someone having access to a PMU
>context and who can trigger this SHA1 computation arbitrarily in task
>local context can run very accurate and low noise timing attacks...
>
>I don't th
On Wed, Oct 02, 2013 at 02:45:41PM +0200, Frederic Weisbecker wrote:
> On Tue, Oct 01, 2013 at 06:59:57PM +0200, Peter Zijlstra wrote:
> > On Tue, Oct 01, 2013 at 06:47:10PM +0200, Frederic Weisbecker wrote:
> > > Yeah thinking more about it, the preempt disable was probably n
On Wed, Oct 02, 2013 at 02:59:32PM +0200, Stephane Eranian wrote:
> On Wed, Oct 2, 2013 at 2:46 PM, Peter Zijlstra wrote:
> > On Wed, Oct 02, 2013 at 02:39:53PM +0200, Ingo Molnar wrote:
> >> - then there are timing attacks, and someone having access to a PMU
> >>
On Wed, Oct 02, 2013 at 02:13:56PM +0200, Oleg Nesterov wrote:
> In short: unless a gp elapses between _exit() and _enter(), the next
> _enter() does nothing and avoids synchronize_sched().
That does however make the entire scheme entirely writer biased;
increasing the need for the waitcount thing
On Wed, Oct 02, 2013 at 03:13:16PM +0200, Stephane Eranian wrote:
> On Wed, Oct 2, 2013 at 3:01 PM, Peter Zijlstra wrote:
> > On Wed, Oct 02, 2013 at 02:59:32PM +0200, Stephane Eranian wrote:
> >> On Wed, Oct 2, 2013 at 2:46 PM, Peter Zijlstra
> >> wrote:
> >
--
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 at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
(&xxx->counter);
}
except: it records the state and synchronize_sched() is only called by
xxx_enter() and only if necessary.
Signed-off-by: Peter Zijlstra
Link: http://lkml.kernel.org/r/20130929183634.ga15...@redhat.com
---
include/linux/rcusync.h | 64
kernel/Ma
The current cpu hotplug lock is a single global lock; therefore excluding
hotplug is a very expensive proposition even though it is rare occurence under
normal operation.
There is a desire for a more light weight implementation of
{get,put}_online_cpus() from both the NUMA scheduling as well as th
Use the fancy new rcu_sync bits from Oleg to optimize the fancy new
hotplug lock implementation.
Signed-off-by: Peter Zijlstra
---
include/linux/cpu.h |7 ---
kernel/cpu.c| 52 +++-
2 files changed, 27 insertions(+), 32 deletions
l and Oleg; many
thanks to them for persisting to poke holes in my attempts.
Signed-off-by: Peter Zijlstra
---
include/linux/cpu.h | 67 ++
include/linux/sched.h |3
kernel/cpu.c | 226 --
kernel/sched/core.c |2
On Wed, Oct 02, 2013 at 04:00:20PM +0200, Oleg Nesterov wrote:
> And again, even
>
> for (;;) {
> percpu_down_write();
> percpu_up_write();
> }
>
> should not completely block the readers.
Sure there's a tiny window, but don't forget that a reader will hav
On Wed, Oct 02, 2013 at 10:09:03AM -0400, Waiman Long wrote:
> v3->v4:
> - Optimize the fast path with better cold cache behavior and
>performance.
> - Removing some testing code.
> - Make x86 use queue rwlock with no user configuration.
> arch/x86/Kconfig |1 +
>
On Wed, Oct 02, 2013 at 10:25:07AM -0700, Andi Kleen wrote:
> > Why are you doing this; also what's up with 11/11?
>
> I was playing with a static checker, and posted some
> of the fixes from looking at the warnings.
> There were 11 patches in the series
>
> Only one is perf related.
It would he
On Wed, Oct 02, 2013 at 11:10:15AM -0700, Kees Cook wrote:
> Seems like a simple enough solution. Surely there must be a catch. :)
I didn't want to add this to the core mm just for perf..
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord.
On Wed, Oct 02, 2013 at 12:38:54PM -0700, Kees Cook wrote:
> On Wed, Oct 2, 2013 at 12:00 PM, Peter Zijlstra wrote:
> > On Wed, Oct 02, 2013 at 11:10:15AM -0700, Kees Cook wrote:
> >> Seems like a simple enough solution. Surely there must be a catch. :)
> >
> > I
On Thu, Oct 03, 2013 at 09:04:59AM +0200, Ingo Molnar wrote:
>
> * Peter Zijlstra wrote:
>
> >
>
> Fully agreed! :-)
haha.. never realized I send that email completely empty. It was
supposed to contain the patch I later send as 2/3.
--
To unsubscribe from thi
est on latest acme's tree.
> >>>
> >>> I'm dealing with some other issues right now, so just reporting ;-)
> >>
> >> The capability bits have changed positions. You need to have:
> >>
> >> commit fa7315871046b9a4c48627905
On Thu, Oct 03, 2013 at 10:56:25AM +0200, Peter Zijlstra wrote:
> > No the ABI is broken in that case - better to crash.
>
> No; neither case should crash.
OK; previously we would report cap_usr_time = 1 even though we might not
have written stuff into the fields; which would indeed
On Thu, Oct 03, 2013 at 10:55:28AM +0200, Stephane Eranian wrote:
> I don't know the MM code but I assume that that vm_mm struct is
> allocated dynamically
> and maybe you already grabbing a lock while doing this. Could we
> leverage that lock
> to increment a global generation number?
Sure; somet
On Thu, Oct 03, 2013 at 12:54:32PM +0300, Adrian Hunter wrote:
> Where do you see that?
my minds eye.. I should go back to sleep or so :-( Its going to be one
of those days.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel
On Thu, Oct 03, 2013 at 01:13:45PM +0300, Adrian Hunter wrote:
> > Anyway; looking at this, why does time_zero have these different checks
> > from the other time bits?
> >
> > @@ -1897,6 +1898,11 @@ void arch_perf_update_userpage(struct
> > perf_event_mmap_page *userpg, u64 now)
> > user
On Thu, Oct 03, 2013 at 09:21:00AM +0200, Ingo Molnar wrote:
> It was important to me and other maintainers as well back then and today
> as well, as me and others complained about it out numerous times.
I can testify to that; the lack of these preemption checks have wasted
hours of my and Thomas
On Thu, Oct 03, 2013 at 02:49:09PM +0300, Adrian Hunter wrote:
> You can boot with notsc and perf still seems to work
> e.g.
>
> $ dmesg | grep -i tsc
> [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-3.11.0+
> root=UUID=f1b4c71a-15aa-41a6-8898-cdde49966bce ro ignore_loglevel
> earlyprintk
On Wed, Oct 02, 2013 at 04:56:56PM +0200, Peter Zijlstra wrote:
> + if (atomic_dec_and_test(&cpuhp_waitcount))
> + wake_up(&cpuhp_writer);
> +
> + goto again:
> }
> +
On Thu, Sep 12, 2013 at 02:38:49PM -0400, Dave Jones wrote:
> The current one I'm staring at is this from LIST_DEBUG..
>
> list_del corruption. next->prev should be prev (88000fb812b0), but was
> 88000fb812b0. (next=88009df8b7b0).
>
> The sharp eyed will notice that those first two
On Thu, Oct 03, 2013 at 09:41:17AM -0700, Paul E. McKenney wrote:
> On Wed, Oct 02, 2013 at 04:56:57PM +0200, Peter Zijlstra wrote:
> #ifdef CONFIG_PROVE_RCU
> #define rcu_sync_is_idle_check(rss) BUG_ON(!rss->read_side_check())
> #else
> #define rcu_sync_is_idle_check(rs
On Thu, Oct 03, 2013 at 09:48:38AM -0700, Paul E. McKenney wrote:
> > -enum { readers_fast = 0, readers_slow, readers_block };
> > +enum { readers_slow, readers_block };
>
> It took me a bit to realize that readers_fast is obsoleted by the
> rcu_sync_is_idle() above. ;-)
Yeah.. I pondered changi
That's not tty; that's RCU..
On Thu, Oct 03, 2013 at 03:08:30PM -0400, Dave Jones wrote:
> ==
> [ INFO: possible circular locking dependency detected ]
> 3.12.0-rc3+ #92 Not tainted
> ---
>
On Thu, Oct 03, 2013 at 12:58:32PM -0700, Paul E. McKenney wrote:
> On Thu, Oct 03, 2013 at 09:42:26PM +0200, Peter Zijlstra wrote:
> >
> > That's not tty; that's RCU..
> >
> > On Thu, Oct 03, 2013
On Thu, Oct 03, 2013 at 10:14:57PM +0200, Paolo Bonzini wrote:
> Do you need to do the same in rcu_sync_init?
Yes.. I actually did but only send the diff for the header file :/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.ker
401 - 500 of 24297 matches
Mail list logo
