On Thu, Oct 17, 2013 at 03:24:36PM +, Christoph Lameter wrote:
On Thu, 17 Oct 2013, Frederic Weisbecker wrote:
- /* We can run anywhere, unlike our parent keventd(). */
- set_cpus_allowed_ptr(current, cpu_all_mask);
+ /* We can run anywhere kthreadd can run
On Thu, Oct 17, 2013 at 10:50:26AM -0700, Andrew Morton wrote:
On Thu, 17 Oct 2013 18:07:28 +0200 Frederic Weisbecker fweis...@gmail.com
wrote:
Couldn't we instead make kthread children (those created with
kthread_create()) to inherit
kthread initial affinity? Currently kthread's
On Fri, Oct 18, 2013 at 04:27:19PM +0200, Petr Mladek wrote:
[...]
arch/x86/include/asm/alternative.h | 3 +-
arch/x86/kernel/alternative.c | 135 ++--
arch/x86/kernel/ftrace.c | 605 ---
arch/x86/kernel/jump_label.c | 3 +-
take is mostly to launch a discussion with a
fresher
base and see if we can find better ideas.
Thanks!
git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git
sched/iowait
Thanks,
Frederic
---
Frederic Weisbecker (5):
nohz: Convert a few places to use local
-by: Frederic Weisbecker fweis...@gmail.com
Cc: Fernando Luis Vazquez Cao fernando...@lab.ntt.co.jp
Cc: Tetsuo Handa penguin-ker...@i-love.sakura.ne.jp
Cc: Thomas Gleixner t...@linutronix.de
Cc: Ingo Molnar mi...@kernel.org
Cc: Peter Zijlstra pet...@infradead.org
Cc: Andrew Morton a...@linux-foundation.org
A few functions use remote per CPU access APIs when they
deal with local values.
Just to the right conversion to improve performance, code
readability and debug checks.
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
Cc: Fernando Luis Vazquez Cao fernando...@lab.ntt.co.jp
Cc: Tetsuo Handa
, it results in another
ABI change on /proc/timer_list for this field.
/proc/stat and other callers of get_cpu_idle_time_us() and
get_cpu_iowait_time_us() are not concerned though because we maintain
the old ABI by substracting the iowait time from the idle time.
Signed-off-by: Frederic Weisbecker
-by: Frederic Weisbecker fweis...@gmail.com
Cc: Fernando Luis Vazquez Cao fernando...@lab.ntt.co.jp
Cc: Tetsuo Handa penguin-ker...@i-love.sakura.ne.jp
Cc: Thomas Gleixner t...@linutronix.de
Cc: Ingo Molnar mi...@kernel.org
Cc: Peter Zijlstra pet...@infradead.org
Cc: Andrew Morton a...@linux
.
So this patch is a just a fresher base to debate on a better solution.
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
Cc: Fernando Luis Vazquez Cao fernando...@lab.ntt.co.jp
Cc: Tetsuo Handa penguin-ker...@i-love.sakura.ne.jp
Cc: Thomas Gleixner t...@linutronix.de
Cc: Ingo Molnar mi
On Sat, Oct 19, 2013 at 05:35:35PM +0200, Peter Zijlstra wrote:
On Sat, Oct 19, 2013 at 05:17:20PM +0200, Frederic Weisbecker wrote:
+u64 get_cpu_iowait_time_us(int cpu, u64 *last_update_time)
+{
+ ktime_t iowait, delta = { .tv64 = 0 };
+ struct rq *rq = cpu_rq(cpu);
+ ktime_t now
On Sat, Oct 19, 2013 at 06:05:17PM +0200, Peter Zijlstra wrote:
On Sat, Oct 19, 2013 at 06:02:37PM +0200, Frederic Weisbecker wrote:
I just had a look at delayacct; wth wrote that crap; that too uses
gtod.
I can't find where it does that. kernel/delayacct.c doesn't seem to at
least
local and remote clock read
* Remove dead leftovers
* Optimize the locking by removing unnecessary uses of tasklist lock
* Various other cleanups...
Thanks,
Frederic
---
Frederic Weisbecker (10):
posix-timers: Remove dead thread posix cpu timers caching
posix-timers: Remove
the timer and its associated
ressources by calling timer_delete() after it buries the target
tasks.
Remove this to simplify the code.
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
Cc: Thomas Gleixner t...@linutronix.de
Cc: Ingo Molnar mi...@kernel.org
Cc: Peter Zijlstra pet
Now that we've removed all the optimizations that could
result in NULL timer's targets, we can remove all the
associated special case handling.
Also add some warnings on NULL targets to spot any possible
leftover.
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
Cc: Thomas Gleixner t
concurrent
timer firing.
The rest only need the targets sighand to be locked.
So hold it and drop the use of tasklist_lock there.
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
Cc: Thomas Gleixner t...@linutronix.de
Cc: Ingo Molnar mi...@kernel.org
Cc: Peter Zijlstra pet...@infradead.org
Cc: Oleg
The posix cpu timers code makes a heavy use of BUG_ON()
but none of these concern fatal issues that require
to stop the machine. So let's just warn the user when
some internal state slips out of our hands.
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
Cc: Thomas Gleixner t
instead.
Also update the comments about locking.
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
Cc: Thomas Gleixner t...@linutronix.de
Cc: Ingo Molnar mi...@kernel.org
Cc: Peter Zijlstra pet...@infradead.org
Cc: Oleg Nesterov o...@redhat.com
Cc: Kosaki Motohiro kosaki.motoh...@jp.fujitsu.com
result in group leader that can change
To protect against these, locking the target's sighand is enough.
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
Cc: Thomas Gleixner t...@linutronix.de
Cc: Ingo Molnar mi...@kernel.org
Cc: Peter Zijlstra pet...@infradead.org
Cc: Oleg Nesterov o
deal as this actually harmonize
the behaviour when the remote sample is actually a local one.
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
Cc: Thomas Gleixner t...@linutronix.de
Cc: Ingo Molnar mi...@kernel.org
Cc: Peter Zijlstra pet...@infradead.org
Cc: Oleg Nesterov o...@redhat.com
Cc
a0b2062b0904ef07944c4a6e4d0f88ee44f1e9f2
(posix_timers: fix racy timer delta caching on task exit) forgot
to remove the arguments used for timer caching.
Fix this leftover.
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
Cc: Thomas Gleixner t...@linutronix.de
Cc: Ingo Molnar mi
get
rid of it.
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
Cc: Thomas Gleixner t...@linutronix.de
Cc: Ingo Molnar mi...@kernel.org
Cc: Peter Zijlstra pet...@infradead.org
Cc: Oleg Nesterov o...@redhat.com
Cc: Kosaki Motohiro kosaki.motoh...@jp.fujitsu.com
Cc: Andrew Morton a...@linux
doesn't seem to be justified.
Given that it complicates the code significantly for
few wins, let's remove it on single thread timers.
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
Cc: Thomas Gleixner t...@linutronix.de
Cc: Ingo Molnar mi...@kernel.org
Cc: Peter Zijlstra pet...@infradead.org
It was initially a single patch that Oleg sent me a few weeks ago. Thinking
about it I think it may need a stable backport even though it doesn't look
very dangerous, but just in case.
So I've splitted the patch in 4 different parts because it may need
backporting on different tree version for
.
Signed-off-by: Oleg Nesterov o...@redhat.com
Fixes: 0067f1297241ea567f2b22a455519752d70fcca9
Cc: sta...@vger.kernel.org
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
---
arch/x86/kernel/hw_breakpoint.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel
...@vger.kernel.org
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
---
arch/arm64/kernel/hw_breakpoint.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/kernel/hw_breakpoint.c
b/arch/arm64/kernel/hw_breakpoint.c
index ff516f6..4bbbfde 100644
--- a/arch/arm64
...@vger.kernel.org
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
---
arch/sh/kernel/hw_breakpoint.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/sh/kernel/hw_breakpoint.c b/arch/sh/kernel/hw_breakpoint.c
index f917376..9801674 100644
--- a/arch/sh/kernel
...@vger.kernel.org
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
---
arch/arm/kernel/hw_breakpoint.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/kernel/hw_breakpoint.c b/arch/arm/kernel/hw_breakpoint.c
index 3d44660..8b38001 100644
--- a/arch/arm/kernel
On Sat, Nov 30, 2013 at 03:11:06PM +0100, Ingo Molnar wrote:
* Ingo Molnar mi...@kernel.org wrote:
* Frederic Weisbecker fweis...@gmail.com wrote:
Ingo,
Please pull the timers/core branch that can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/frederic
...@kernel.org
Suggested-by: Frederic Weisbecker fweis...@gmail.com
Thanks a lot for doing this Namhyung!
--
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
On Sat, Nov 30, 2013 at 02:59:07PM +0100, Ingo Molnar wrote:
* Frederic Weisbecker fweis...@gmail.com wrote:
Ingo,
Please pull the timers/core branch that can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git
timers/core
It passed
On Sat, Nov 23, 2013 at 04:37:10PM +0100, Frederic Weisbecker wrote:
Ingo, Thomas,
Please pull the timers/posix-timers-for-tip branch that can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git
timers/posix-timers-for-tip
HEAD
2013/11/11 Oleg Nesterov o...@redhat.com:
On 11/11, Frederic Weisbecker wrote:
On Sat, Nov 09, 2013 at 04:54:28PM +0100, Oleg Nesterov wrote:
Up to you and Suravee, but can't we cleanup this later?
This series was updated many times to address a lot of (sometimes
contradictory
instead.
Also update the comments about locking.
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
Cc: Thomas Gleixner t...@linutronix.de
Cc: Ingo Molnar mi...@kernel.org
Cc: Peter Zijlstra pet...@infradead.org
Cc: Oleg Nesterov o...@redhat.com
Cc: Kosaki Motohiro kosaki.motoh...@jp.fujitsu.com
Now that we've removed all the optimizations that could
result in NULL timer's targets, we can remove all the
associated special case handling.
Also add some warnings on NULL targets to spot any possible
leftover.
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
Cc: Thomas Gleixner t
a0b2062b0904ef07944c4a6e4d0f88ee44f1e9f2
(posix_timers: fix racy timer delta caching on task exit) forgot
to remove the arguments used for timer caching.
Fix this leftover.
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
Cc: Thomas Gleixner t...@linutronix.de
Cc: Ingo Molnar mi
The posix cpu timers code makes a heavy use of BUG_ON()
but none of these concern fatal issues that require
to stop the machine. So let's just warn the user when
some internal state slips out of our hands.
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
Cc: Thomas Gleixner t
result in group leader that can change
To protect against these, locking the target's sighand is enough.
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
Cc: Thomas Gleixner t...@linutronix.de
Cc: Ingo Molnar mi...@kernel.org
Cc: Peter Zijlstra pet...@infradead.org
Cc: Oleg Nesterov o
concurrent
timer firing.
The rest only need the targets sighand to be locked.
So hold it and drop the use of tasklist_lock there.
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
Cc: Thomas Gleixner t...@linutronix.de
Cc: Ingo Molnar mi...@kernel.org
Cc: Peter Zijlstra pet...@infradead.org
Cc: Oleg
deal as this actually harmonize
the behaviour when the remote sample is actually a local one.
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
Cc: Thomas Gleixner t...@linutronix.de
Cc: Ingo Molnar mi...@kernel.org
Cc: Peter Zijlstra pet...@infradead.org
Cc: Oleg Nesterov o...@redhat.com
Cc
-off-by: Frederic Weisbecker fweis...@gmail.com
Cc: Thomas Gleixner t...@linutronix.de
Cc: Ingo Molnar mi...@kernel.org
Cc: Peter Zijlstra pet...@infradead.org
Cc: Oleg Nesterov o...@redhat.com
Cc: Kosaki Motohiro kosaki.motoh...@jp.fujitsu.com
Cc: Andrew Morton a...@linux-foundation.org
---
kernel
the timer and its associated
ressources by calling timer_delete() after it buries the target
tasks.
Remove this to simplify the code.
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
Cc: Thomas Gleixner t...@linutronix.de
Cc: Ingo Molnar mi...@kernel.org
Cc: Peter Zijlstra pet
like to also make sure
that people are fine with the optimizations I'm removing. So here is it.
Thanks.
git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git
timers/posix-timers-rfc
Thanks,
Frederic
---
Frederic Weisbecker (10):
posix-timers: Remove dead
complicates the code significantly for
few wins, let's remove it on single thread timers.
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
Cc: Thomas Gleixner t...@linutronix.de
Cc: Ingo Molnar mi...@kernel.org
Cc: Peter Zijlstra pet...@infradead.org
Cc: Oleg Nesterov o...@redhat.com
Cc: Kosaki
On Mon, Oct 14, 2013 at 02:28:30PM -0700, Paul E. McKenney wrote:
On Mon, Oct 14, 2013 at 10:53:03AM -0700, Linus Torvalds wrote:
Hmm. No obvious ideas come to mind, but I'm adding more people to the cc.
Clearly the wait_event_interruptible_timeout() in the RCU grace-period
thread causes
On Tue, Oct 15, 2013 at 12:31:34AM +0200, Knut Petersen wrote:
On 14.10.2013 23:51, Frederic Weisbecker wrote:
Also knut, do you have a serial line?
Yes, if really necesarry I´d prefer network
Hmm, you can try but it might not be working correcty after the fault.
If so may
On Tue, Oct 15, 2013 at 02:01:04AM +, Liu, Chuansheng wrote:
We meet one issue that during trigger all CPU backtrace, but during in the
NMI handler arch_trigger_all_cpu_backtrace_handler,
It hit the PAGE fault, then PAGE fault is in loop, at last the thread stack
overflow, and system
On Tue, Oct 15, 2013 at 02:37:17PM +0200, Peter Zijlstra wrote:
On Tue, Oct 15, 2013 at 02:18:53PM +0200, Frederic Weisbecker wrote:
On Tue, Oct 15, 2013 at 02:01:04AM +, Liu, Chuansheng wrote:
We meet one issue that during trigger all CPU backtrace, but during in
the NMI handler
On Tue, Oct 15, 2013 at 05:48:37AM -0700, Paul E. McKenney wrote:
On Tue, Oct 15, 2013 at 02:37:17PM +0200, Peter Zijlstra wrote:
On Tue, Oct 15, 2013 at 02:18:53PM +0200, Frederic Weisbecker wrote:
On Tue, Oct 15, 2013 at 02:01:04AM +, Liu, Chuansheng wrote:
We meet one issue
On Tue, Oct 15, 2013 at 06:06:59AM -0700, Paul E. McKenney wrote:
On Tue, Oct 15, 2013 at 02:59:15PM +0200, Frederic Weisbecker wrote:
On Tue, Oct 15, 2013 at 05:48:37AM -0700, Paul E. McKenney wrote:
On Tue, Oct 15, 2013 at 02:37:17PM +0200, Peter Zijlstra wrote:
On Tue, Oct 15, 2013
On Tue, Oct 15, 2013 at 03:58:06PM -0400, Steven Rostedt wrote:
The WARN_ON_ONCE() code is to trigger a waring only once when some
condition happens. But due to the way it is written it is racy.
if (unlikely(condition)) {
if (WARN(!__warned))
On Tue, Oct 15, 2013 at 01:12:59PM -0700, Andrew Morton wrote:
On Tue, 15 Oct 2013 15:58:06 -0400 Steven Rostedt rost...@goodmis.org wrote:
The WARN_ON_ONCE() code is to trigger a waring only once when some
condition happens. But due to the way it is written it is racy.
if
On Tue, Oct 15, 2013 at 04:25:40PM -0400, Steven Rostedt wrote:
On Tue, 15 Oct 2013 22:18:48 +0200
Frederic Weisbecker fweis...@gmail.com wrote:
How about just updating __warned without a cmpxchg. It's not that critical
if the update is not seen immediately to other CPUs. OTOH it's
On Tue, Oct 15, 2013 at 04:36:22PM -0400, Steven Rostedt wrote:
On Tue, 15 Oct 2013 22:21:36 +0200
Frederic Weisbecker fweis...@gmail.com wrote:
Oh, I have a pending patchset that I worked on a few weeks ago which does
that.
I did not post it because it made WARN_ONCE using the unlikely
Unfortunately this removes the use of .data.unlikely code
section for the warned state...
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
Cc: Andrew Morton a...@linux-foundation.org
Cc: Steven Rostedt rost...@goodmis.org
Cc: Linus Torvalds torva...@linux-foundation.org
Cc: H. Peter Anvin h
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
Cc: Andrew Morton a...@linux-foundation.org
Cc: Steven Rostedt rost...@goodmis.org
Cc: Linus Torvalds torva...@linux-foundation.org
Cc: H. Peter Anvin h...@zytor.com
Cc: Peter Zijlstra pet...@infradead.org
Cc: Thomas Gleixner t...@linutronix.de
Introduce DO_COND(), DO_ONCE() and DO_ONCE_COND(). These
macros should ease the consolidation of CPP code when
it is deemed to be executed only once and/or after a
condition is verified. This incluse printk_once, WARN_ON,
WARN_ON_ONCE, etc...
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
.
git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git
core/once
Thanks,
Frederic
---
Frederic Weisbecker (3):
core: New macro to execute code only once
core: Convert printk_once to use DO_ONCE
bug: Convert warn macros to use once and cond helpers
On Tue, Oct 15, 2013 at 02:00:05PM -0700, Joe Perches wrote:
On Tue, 2013-10-15 at 22:50 +0200, Frederic Weisbecker wrote:
[]
diff --git a/include/linux/printk.h b/include/linux/printk.h
[]
@@ -252,14 +253,7 @@ extern asmlinkage void dump_stack(void) __cold;
#ifdef CONFIG_PRINTK
On Sat, Nov 09, 2013 at 03:10:39PM +0100, Peter Zijlstra wrote:
On Fri, Nov 08, 2013 at 11:36:58PM +0100, Frederic Weisbecker wrote:
[ 237.627769] perf samples too long (3397569 2500), lowering
kernel.perf_event_max_sample_rate to 5
[ 237.637124] INFO: NMI handler
On Sat, Nov 09, 2013 at 03:10:39PM +0100, Peter Zijlstra wrote:
On Fri, Nov 08, 2013 at 11:36:58PM +0100, Frederic Weisbecker wrote:
[ 237.627769] perf samples too long (3397569 2500), lowering
kernel.perf_event_max_sample_rate to 5
[ 237.637124] INFO: NMI handler
On Sat, Nov 09, 2013 at 04:11:01PM +0100, Peter Zijlstra wrote:
On Fri, Nov 08, 2013 at 11:36:58PM +0100, Frederic Weisbecker wrote:
[ 237.359091] [8101a4d1] perf_callchain_kernel+0x51/0x70
[ 237.365155] [8111fec6] perf_callchain+0x256/0x2c0
[ 237.370783
On Sat, Nov 09, 2013 at 04:13:56PM +0100, Peter Zijlstra wrote:
On Sat, Nov 09, 2013 at 03:52:59PM +0100, Frederic Weisbecker wrote:
So, an idea of what may be happening: an event overflows while FASYNC flag
is set so it triggers an irq work
to send the signal (kill_fasync).
After
On Sat, Nov 09, 2013 at 04:11:56PM +0100, Oleg Nesterov wrote:
On 11/08, Frederic Weisbecker wrote:
On Wed, Oct 02, 2013 at 11:11:06AM -0500, suravee.suthikulpa...@amd.com
wrote:
diff --git a/arch/x86/include/asm/cpufeature.h
b/arch/x86/include/asm/cpufeature.h
index d3f5c63
On Sat, Nov 09, 2013 at 04:59:38PM +0100, Peter Zijlstra wrote:
On Sat, Nov 09, 2013 at 04:27:01PM +0100, Frederic Weisbecker wrote:
In fact, raising an irq work from an irq work should simply be prohibited.
That's not a sane
behaviour.
Well, it is because as you raised on IRC we could
On Mon, Nov 11, 2013 at 01:12:12PM +0100, Ingo Molnar wrote:
I'm not sure why you want to add a new -F that adds news way to display
fields. Isn't -s enough for that?
Well, -s implies sorting.
With -F we could decouple sorting from display order, and allow output
like:
# Symbol
On Mon, Nov 11, 2013 at 01:13:52PM +0100, Ingo Molnar wrote:
It's not an irrelevant feature at all! :-)
It's just that for any sort of longer profile it was pretty
difficult/frustrating to use, which I think held back adoption.
That performance problem got fixed now by you and Namhyung,
be delayed for 3.14
Thanks,
Frederic
---
Frederic Weisbecker (5):
nohz: Convert a few places to use local per cpu accesses
context_tracking: Wrap static key check into more intuitive function name
context_tracking: Rename context_tracking_active
On Sat, Nov 09, 2013 at 04:54:28PM +0100, Oleg Nesterov wrote:
Just in case let me repeat, I can be easily wrong because I forgot
how this series actually look and I don't have the patches now ;)
On 11/09, Frederic Weisbecker wrote:
On Sat, Nov 09, 2013 at 04:11:56PM +0100, Oleg Nesterov
On Mon, Nov 11, 2013 at 02:56:37PM +0100, Ingo Molnar wrote:
* Frederic Weisbecker fweis...@gmail.com wrote:
On Mon, Nov 11, 2013 at 01:13:52PM +0100, Ingo Molnar wrote:
It's not an irrelevant feature at all! :-)
It's just that for any sort of longer profile it was pretty
On Sat, Nov 09, 2013 at 12:32:06PM +0400, Alexander Beregalov wrote:
Hi,
It first appeared some time after 3.9 or 3.10 and still persist.
I guess bisect is not required?
WARNING: CPU: 1 PID: 6 at kernel/time/tick-sched.c:187
can_stop_full_tick+0x8d/0x9a()
NO_HZ FULL will not work with
On Tue, Nov 12, 2013 at 09:58:29PM -0700, David Ahern wrote:
Hi Namhyung and Frederic:
If you recall I mentioned noting a problem with the callchain series
showing comm's. Well, it fails on acme's perf/core. git bisect
points to:
$ git bisect bad
4dfced359fbc719a35527416f1b4b3999647f68b
On Wed, Nov 13, 2013 at 03:07:46PM -0300, Arnaldo Carvalho de Melo wrote:
Em Wed, Nov 13, 2013 at 07:03:47PM +0100, Frederic Weisbecker escreveu:
On Tue, Nov 12, 2013 at 09:58:29PM -0700, David Ahern wrote:
Hi Namhyung and Frederic:
If you recall I mentioned noting a problem
On Wed, Nov 13, 2013 at 11:06:11AM -0700, David Ahern wrote:
On 11/13/13, 11:03 AM, Frederic Weisbecker wrote:
I see. I can reproduce, I'll check and see what happens. It would be nice if
we could have an option to dump internal perf events like comm events as well
in the perf script stream
On Thu, Nov 14, 2013 at 04:33:01PM +0100, Peter Zijlstra wrote:
On Thu, Nov 14, 2013 at 04:23:04PM +0100, Peter Zijlstra wrote:
/*
+ * We must dis-allow sampling irq_work_exit() because perf event sampling
+ * itself can cause irq_work, which would lead to an infinite loop;
+ *
+ * 1)
On Thu, Nov 14, 2013 at 04:23:04PM +0100, Peter Zijlstra wrote:
On Sat, Nov 09, 2013 at 04:10:14PM +0100, Peter Zijlstra wrote:
Cute.. so what appears to happen is that:
1) we trace irq_work_exit
2) we generate event
3) event needs to deliver signal
4) we queue irq_work to send
: Frederic Weisbecker fweis...@gmail.com
---
tools/perf/builtin-script.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
index baf17989a216..6f96f8414047 100644
--- a/tools/perf/builtin-script.c
+++ b/tools/perf
On Fri, Nov 15, 2013 at 09:15:21AM -0500, Steven Rostedt wrote:
On Fri, 15 Nov 2013 13:28:33 +0100
Peter Zijlstra pet...@infradead.org wrote:
On Fri, Nov 15, 2013 at 10:16:18AM +0900, Masami Hiramatsu wrote:
Kprobes itself can detect nested call by using per-cpu current-running
kprobe
On Fri, Nov 15, 2013 at 09:29:51AM -0700, David Ahern wrote:
HI Frederic:
On 11/13/13, 11:03 AM, Frederic Weisbecker wrote:
I see. I can reproduce, I'll check and see what happens. It would be nice if
we could have an option to dump internal perf events like comm events as well
On Thu, Oct 03, 2013 at 05:40:40PM +, Christoph Lameter wrote:
V2-V3:
- Introduce a new tick_get_housekeeping_cpu() function. Not sure
if that is exactly what we want but it is a start. Thomas?
Not really. Thomas suggested an infrastructure to move CPU-local periodic
jobs handling to be
On Mon, Nov 18, 2013 at 03:10:21PM +0100, Peter Zijlstra wrote:
--- a/kernel/softirq.c
+++ b/kernel/softirq.c
@@ -746,13 +746,23 @@ void irq_exit(void)
#endif
account_irq_exit_time(current);
- trace_hardirq_exit();
sub_preempt_count(HARDIRQ_OFFSET);
- if
the fact that
softirqs can be called from hardirqs while hardirqs can nest on softirqs
but those two cases have very different semantics and only the latter
case assume both states.
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
Cc: Sebastian Andrzej Siewior bige...@linutronix.de
Cc: Peter
On Wed, Nov 20, 2013 at 01:07:34AM +0100, Frederic Weisbecker wrote:
Instead of saving the hardirq state on a per CPU variable, which require
an explicit call before the softirq handling and some complication,
just save and restore the hardirq tracing state through functions
return values
On Tue, Nov 19, 2013 at 08:21:45PM +0100, Oleg Nesterov wrote:
DR6_RESERVED and DR_CONTROL_RESERVED are used to clear the unwanted
bits in the unsigned long data, but ulong = ~int also clears the
upper bits that are not specified in mask.
This is actually fine, dr6[32:63] are reserved, but
, dso and ip if callchains are present
Signed-off-by: David Ahern dsah...@gmail.com
Cc: Frederic Weisbecker fweis...@gmail.com
Thanks, looks good, just a few things:
---
tools/perf/builtin-script.c | 24
1 file changed, 24 insertions(+)
diff --git a/tools/perf
(not a regression though as it only impacts full dynticks and
the
bug is there since we merged full dynticks).
Let me know if you find any issue.
Thanks,
Frederic
---
Frederic Weisbecker (5):
nohz: Convert a few places to use local per cpu accesses
context_tracking: Wrap
as expected
This patch fixes this bug by handling both cases in one. All we need
is to move the kick to the rearming common code in posix_cpu_timer_schedule().
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
Cc: Thomas Gleixner t...@linutronix.de
Cc: Ingo Molnar mi...@kernel.org
Cc: Peter Zijlstra pet
Use a function with a meaningful name to check the global context
tracking state. static_key_false() is a bit confusing for reviewers.
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
Cc: Thomas Gleixner t...@linutronix.de
Cc: Ingo Molnar mi...@kernel.org
Cc: Peter Zijlstra pet
.
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
Cc: Thomas Gleixner t...@linutronix.de
Cc: Ingo Molnar mi...@kernel.org
Cc: Peter Zijlstra pet...@infradead.org
Cc: Oleg Nesterov o...@redhat.com
Cc: Steven Rostedt rost...@goodmis.org
---
include/linux/tick.h | 6 +++---
kernel
-off-by: Frederic Weisbecker fweis...@gmail.com
Cc: Thomas Gleixner t...@linutronix.de
Cc: Ingo Molnar mi...@kernel.org
Cc: Peter Zijlstra pet...@infradead.org
Cc: Oleg Nesterov o...@redhat.com
Cc: Steven Rostedt rost...@goodmis.org
---
kernel/posix-cpu-timers.c | 3 ++-
1 file changed, 2
.
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
Cc: Thomas Gleixner t...@linutronix.de
Cc: Ingo Molnar mi...@kernel.org
Cc: Peter Zijlstra pet...@infradead.org
Cc: Oleg Nesterov o...@redhat.com
Cc: Steven Rostedt rost...@goodmis.org
---
include/linux/context_tracking_state.h | 9
From: Paul Gortmaker paul.gortma...@windriver.com
Signed-off-by: Paul Gortmaker paul.gortma...@windriver.com
Signed-off-by: Frederic Weisbecker fweis...@gmail.com
Cc: Thomas Gleixner t...@linutronix.de
Cc: Ingo Molnar mi...@kernel.org
Cc: Peter Zijlstra pet...@infradead.org
Cc: Oleg Nesterov o
On Wed, Dec 04, 2013 at 02:04:09PM +0100, Oleg Nesterov wrote:
while_each_thread() and next_thread() should die, almost every
lockless usage is wrong.
1. Unless g == current, the lockless while_each_thread() is not safe.
while_each_thread(g, t) can loop forever if g exits, next_thread()
On Wed, Dec 04, 2013 at 02:49:17PM +0100, Oleg Nesterov wrote:
On 12/04, Frederic Weisbecker wrote:
On Wed, Dec 04, 2013 at 02:04:09PM +0100, Oleg Nesterov wrote:
For example, do/while_each_thread() always
sees at least one task, while for_each_thread() can do nothing if
the whole
On Wed, Dec 04, 2013 at 01:50:34PM -0500, KOSAKI Motohiro wrote:
@@ -1090,13 +1063,8 @@ void posix_cpu_timer_schedule(struct k_itimer *timer)
timer-it.cpu.expires = 0;
goto out_unlock;
} else if (unlikely(p-exit_state)
On Wed, Dec 04, 2013 at 11:39:57AM -0800, Paul E. McKenney wrote:
Hello, Frederic,
Just realized that I could further decrease RT latency of one of my shut
up RCU on NO_HZ_FULL CPUs patches if I relied on CPU 0 always having
a scheduling-clock tick unless the entire system is idle. The
2013/11/28 Oleg Nesterov o...@redhat.com:
call_usermodehelper() does set_cpus_allowed_ptr(cpu_all_mask),
this (and the comment) is misleading. We no longer have keventd_wq,
and kmod.c switched to khelper_wq a long ago.
And more importantly, unlike our parent is no longer true too,
this
On Thu, Dec 05, 2013 at 03:37:45PM +0100, Oleg Nesterov wrote:
On 12/05, Frederic Weisbecker wrote:
2013/11/28 Oleg Nesterov o...@redhat.com:
call_usermodehelper() does set_cpus_allowed_ptr(cpu_all_mask),
this (and the comment) is misleading. We no longer have keventd_wq
On Thu, Dec 05, 2013 at 09:39:03AM -0500, Tejun Heo wrote:
Hello,
On Thu, Dec 05, 2013 at 03:37:45PM +0100, Oleg Nesterov wrote:
I'm adding Christophe in Cc because he is interested in tweaking the
affinity of call_usermodehelper for cpu isolation. This welcome
cleanup confirms that
On Wed, Mar 12, 2014 at 10:44:47AM +0100, Peter Zijlstra wrote:
On Wed, Mar 12, 2014 at 03:10:02AM +0100, Frederic Weisbecker wrote:
diff --git a/arch/alpha/include/asm/Kbuild b/arch/alpha/include/asm/Kbuild
index a73a8e2..1a81a8b 100644
--- a/arch/alpha/include/asm/Kbuild
+++ b/arch
On Wed, Mar 12, 2014 at 04:26:44PM +0100, Peter Zijlstra wrote:
On Wed, Mar 12, 2014 at 04:23:28PM +0100, Frederic Weisbecker wrote:
On Wed, Mar 12, 2014 at 10:44:47AM +0100, Peter Zijlstra wrote:
On Wed, Mar 12, 2014 at 03:10:02AM +0100, Frederic Weisbecker wrote:
diff --git a/arch
1101 - 1200 of 8299 matches
Mail list logo
