This also removes a needless clockevent write on idle ticks. Since those
clock write are usually considered to be slow, it's a general win.
Reviewed-by: Preeti U Murthy
Signed-off-by: Viresh Kumar
Cc: Thomas Gleixner
Signed-off-by: Frederic Weisbecker
---
kernel/time/tick-sched.c | 4
1
On Thu, Sep 04, 2014 at 08:11:37AM +0200, Peter Zijlstra wrote:
> On Thu, Aug 21, 2014 at 04:52:51PM +0200, Frederic Weisbecker wrote:
> > diff --git a/kernel/irq_work.c b/kernel/irq_work.c
> > index e6bcbe7..17bd203 100644
> > --- a/kernel/irq_work.c
> > +++ b/kernel/ir
On Thu, Sep 04, 2014 at 10:07:37PM +0200, Catalin Iacob wrote:
> On Tue, Sep 2, 2014 at 8:23 PM, Catalin Iacob wrote:
> > On Mon, Sep 1, 2014 at 10:14 PM, Frederic Weisbecker
> > wrote:
> >> I'll send "nohz: Restore NMI safe local irq work for local nohz ki
NMI-unsafe. But perf needs to use this kick from NMIs.
This patch fixes the issue by restoring the old NMI-safe internals of
the API.
Thanks,
Frederic
---
Frederic Weisbecker (1):
nohz: Restore NMI safe local irq work for local nohz kick
include/linux/tick.h | 7 +--
kernel
On Thu, Sep 04, 2014 at 11:05:02PM +0200, Catalin Iacob wrote:
> On Thu, Sep 4, 2014 at 10:17 PM, Frederic Weisbecker
> wrote:
> > Yeah, that's expected. You need to apply the nine patches on top of -rc1:
> >
> > git://git.kernel.org/pub/scm/linux/kernel/gi
On Thu, Sep 04, 2014 at 05:40:20PM +0200, Peter Zijlstra wrote:
> On Thu, Sep 04, 2014 at 03:33:40PM +0200, Frederic Weisbecker wrote:
> > > Why not something like the below; then it becomes a compile time matter.
> >
> > Problem is that some archs only have that informa
On Thu, Sep 04, 2014 at 08:11:37AM +0200, Peter Zijlstra wrote:
> On Thu, Aug 21, 2014 at 04:52:51PM +0200, Frederic Weisbecker wrote:
> > diff --git a/kernel/irq_work.c b/kernel/irq_work.c
> > index e6bcbe7..17bd203 100644
> > --- a/kernel/irq_work.c
> > +++ b/kernel/ir
On Sat, Sep 06, 2014 at 05:45:56PM +0200, Peter Zijlstra wrote:
> On Sat, Sep 06, 2014 at 03:35:15PM +0200, Frederic Weisbecker wrote:
> > You have a script that does that arch/*/include/asm/Kbuild edit for you
> > right?
> > Is this something in scripts/ ?
>
> See co
On Fri, Aug 22, 2014 at 10:00:09AM -0400, Dave Jones wrote:
> On Fri, Aug 22, 2014 at 08:01:48AM +0200, Catalin Iacob wrote:
> > On Thu, Aug 21, 2014 at 4:56 PM, Frederic Weisbecker
> wrote:
> > > Can you please test the series I just posted: "[RFC PATCH 0/9] nohz:
&
On Wed, Aug 06, 2014 at 07:01:51PM +0200, Peter Zijlstra wrote:
> > Sigh, that's d84153d6c96f61a so that's been there a while, and been
> > broken equally long.
> >
> > So this is where we run a low period (!freq) hardware event on a
> > nohz_full cpu or so? And because it throttles, we need to ki
On Thu, Aug 07, 2014 at 10:13:21AM +0200, Peter Zijlstra wrote:
> On Thu, Aug 07, 2014 at 01:44:58AM +0200, Frederic Weisbecker wrote:
> > In fact the problem has arised since the recent irq work patches I did.
>
> No, those just added the WARN, previously we send the resched IP
On Thu, Aug 07, 2014 at 11:03:33AM +0200, Peter Zijlstra wrote:
> On Wed, Aug 06, 2014 at 03:46:56PM -0400, Dave Jones wrote:
> > This one happened during runtime, but I got a whole stack..
> >
> >
> > Kernel panic - not syncing: Watchdog detected hard LOCKUP on cpu 2
> > CPU: 2 PID: 7538 Comm:
On Thu, Aug 07, 2014 at 03:15:36PM +0200, Peter Zijlstra wrote:
> On Thu, Aug 07, 2014 at 02:58:55PM +0200, Frederic Weisbecker wrote:
> > On Thu, Aug 07, 2014 at 10:13:21AM +0200, Peter Zijlstra wrote:
> > > On Thu, Aug 07, 2014 at 01:44:58AM +0200, Frederic Weisbecker wrote:
&
On Mon, Aug 04, 2014 at 05:03:42AM +0200, Denys Vlasenko wrote:
> On Sat, Aug 2, 2014 at 1:19 AM, Frederic Weisbecker
> wrote:
> >> CFI_ESCAPE 0x0f /* DW_CFA_def_cfa_expression */, 6, \
> >> 0x77 /* DW_OP_breg7 */, 0, \
> &g
Ping?
On Thu, Jul 31, 2014 at 06:45:54PM +0200, Frederic Weisbecker wrote:
> Hi Thomas,
>
> The tick reschedules itself unconditionally. That's what we want as long
> as the CPU is in periodic mode. It's not that relevant when the CPU
> is in dynticks mode though as the
On Wed, Aug 13, 2014 at 05:03:24PM -0400, Rik van Riel wrote:
> --- a/kernel/time/posix-cpu-timers.c
> +++ b/kernel/time/posix-cpu-timers.c
> @@ -272,22 +272,8 @@ static int posix_cpu_clock_get_task(struct task_struct
> *tsk,
> if (same_thread_group(tsk, current))
>
2014-08-14 3:57 GMT+02:00 Rik van Riel :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 08/13/2014 08:43 PM, Frederic Weisbecker wrote:
>> On Wed, Aug 13, 2014 at 05:03:24PM -0400, Rik van Riel wrote:
>>> --- a/kernel/time/posix-cpu-timers.c +++
>>&
2014-08-14 15:22 GMT+02:00 Oleg Nesterov :
> On 08/13, Rik van Riel wrote:
>>
>> On Wed, 13 Aug 2014 20:45:11 +0200
>> Oleg Nesterov wrote:
>>
>> > That said, it is not that I am really sure that seqcount_t in ->signal
>> > is actually worse, not to mention that this is subjective anyway. IOW,
>>
2014-08-14 16:39 GMT+02:00 Oleg Nesterov :
> On 08/14, Frederic Weisbecker wrote:
>>
>> 2014-08-14 3:57 GMT+02:00 Rik van Riel :
>> > -BEGIN PGP SIGNED MESSAGE-
>> > Hash: SHA1
>> >
>> > On 08/13/2014 08:43 PM, Frederic Weisbecker wrote:
On Fri, Aug 15, 2014 at 04:26:01PM +0200, Oleg Nesterov wrote:
> On 08/15, Frederic Weisbecker wrote:
> >
> > 2014-08-14 16:39 GMT+02:00 Oleg Nesterov :
> > > On 08/14, Frederic Weisbecker wrote:
> > >>
> > >> I mean the read side doesn't use a
On Thu, Jul 31, 2014 at 07:04:16PM -0700, Paul E. McKenney wrote:
> On Fri, Aug 01, 2014 at 01:57:50AM +0200, Frederic Weisbecker wrote:
> >
> > So this thread is going to poll every second? I guess something prevents it
> > to run when system is idle somewhere? But I&#x
On Fri, Aug 01, 2014 at 01:16:05PM -0400, Chris Metcalf wrote:
> On 7/31/2014 9:39 PM, Lai Jiangshan wrote:
> >On 08/01/2014 12:09 AM, Chris Metcalf wrote:
> >>On 7/31/2014 7:51 AM, Michal Hocko wrote:
> >>>On Thu 31-07-14 11:30:19, Lai Jiangshan wrote:
> It is suggested that cpumask_var_t and
On Fri, Aug 01, 2014 at 04:48:14PM +0200, Denys Vlasenko wrote:
> A define, two macros and an unreferenced bit of assembly are gone.
>
> Signed-off-by: Denys Vlasenko
> CC: Oleg Nesterov
> CC: "H. Peter Anvin"
> CC: Andy Lutomirski
Acked-by: Frederic Weisbecker
irski
One macro dissolved == one Hop-o'-My-Thumb pebble less to drop before taking
a jump on the editor.
Acked-by: Frederic Weisbecker
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo
> (four instances).
>
> Patch was run-tested: 64-bit executables, 32-bit executables,
> strace works.
>
> Signed-off-by: Denys Vlasenko
> CC: Oleg Nesterov
> CC: "H. Peter Anvin"
> CC: Andy Lutomirski
> CC: Frederic Weisbecker
> CC: X86 ML
&g
On Fri, Aug 01, 2014 at 04:48:17PM +0200, Denys Vlasenko wrote:
>
> /* 0(%rsp): ~(interrupt number) */
> .macro interrupt func
> - /* reserve pt_regs for scratch regs and rbp */
> - subq $ORIG_RAX-RBP, %rsp
> - CFI_ADJUST_CFA_OFFSET ORIG_RAX-RBP
> - cld
> - /* start fro
On Wed, Oct 22, 2014 at 02:35:47PM +0200, Peter Zijlstra wrote:
> On Mon, Oct 13, 2014 at 04:45:30PM +0300, Alexander Shishkin wrote:
> > + struct kref aux_refcount;
>
> I'm not a fan of kref, pointless obfuscation that.
It has a good potential for debugging though. Sure rig
On Thu, Oct 02, 2014 at 02:24:09PM -0400, Dave Jones wrote:
> On Fri, Sep 26, 2014 at 01:46:59AM +0200, Frederic Weisbecker wrote:
>
> > > > [] hrtimer_try_to_cancel+0x58/0x1f0
> > > > [] hrtimer_cancel+0x1a/0x30
> > > > [] tick_nohz_restart+0x1
Thanks,
Frederic
---
Frederic Weisbecker (7):
nohz: Move nohz full init call to tick init
irq_work: Force raised irq work to run on irq work interrupt
x86: Tell irq work about self IPI support
arm: Tell irq work about self IPI support
arm64: Tell irq work about
advice and pseudo code from Oleg Nesterov
Signed-off-by: Jacob Shin
Signed-off-by: Suravee Suthikulpanit
Acked-by: Jiri Olsa
Reviewed-by: Oleg Nesterov
Cc: Arnaldo Carvalho de Melo
Cc: Ingo Molnar
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: xiakaixu
Signed-off-by: Frederic Weisbecker
---
arch
From: Jacob Shin
Signed-off-by: Jacob Shin
Signed-off-by: Suravee Suthikulpanit
Acked-by: Jiri Olsa
Reviewed-by: Oleg Nesterov
Cc: Arnaldo Carvalho de Melo
Cc: Ingo Molnar
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: xiakaixu
Signed-off-by: Frederic Weisbecker
---
tools/perf/tests/parse
: Suravee Suthikulpanit
Acked-by: Jiri Olsa
Reviewed-by: Oleg Nesterov
Cc: Arnaldo Carvalho de Melo
Cc: Ingo Molnar
Cc: Namhyung Kim
Cc: Peter Zijlstra
Cc: xiakaixu
Signed-off-by: Frederic Weisbecker
---
tools/perf/Documentation/perf-record.txt | 7 +--
tools/perf/util/parse-events.c
Ingo,
Please pull the perf/core-v2 branch that can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git
perf/core-v2
HEAD: 33252c1bb36dd7405f412a9ef8fc05dec995064a
It has been acked by Jiri and Oleg.
---
Summary:
* Extend breakpoint tools and core to s
-off-by: Frederic Weisbecker
---
arch/x86/kernel/hw_breakpoint.c | 25 +
1 file changed, 1 insertion(+), 24 deletions(-)
diff --git a/arch/x86/kernel/hw_breakpoint.c b/arch/x86/kernel/hw_breakpoint.c
index 91ce081..edb70e9 100644
--- a/arch/x86/kernel/hw_breakpoint.c
+++ b
2014-10-25 2:22 GMT+02:00 Andy Lutomirski :
> Is there any good reason not to use vmalloc for x86_64 stacks?
>
> The tricky bits I've thought of are:
>
> - On any context switch, we probably need to probe the new stack
> before switching to it. That way, if it's going to fault due to an
> out-of-
On Sat, Oct 25, 2014 at 10:49:25PM -0700, Andy Lutomirski wrote:
> On Oct 25, 2014 9:11 PM, "Frederic Weisbecker" wrote:
> >
> > 2014-10-25 2:22 GMT+02:00 Andy Lutomirski :
> > > Is there any good reason not to use vmalloc for x86_64 stacks?
> > >
Leftover from early code.
Cc: Christoph Lameter
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Preeti U Murthy
Cc: Rik van Riel
Cc: Thomas Gleixner
Cc: Viresh Kumar
Signed-off-by: Frederic Weisbecker
---
include/linux/tick.h | 8
kernel/sched/core.c | 2 +-
kernel/time/tick
s.git
timers/core-v4
HEAD: 2e9d80bececd2cb49aeddaf61660de76730559f9
Thanks,
Frederic
---
Frederic Weisbecker (10):
nohz: Remove idle task special case
nohz: Restart nohz full tick from irq exit
nohz: Move tick_nohz_restart_sched_tick() above its users
Fix the function declaration/definition dance.
Reviewed-by: Rik van Riel
Cc: Christoph Lameter
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Preeti U Murthy
Cc: Rik van Riel
Cc: Thomas Gleixner
Cc: Viresh Kumar
Signed-off-by: Frederic Weisbecker
---
kernel/time/tick-sched.c | 34
Kumar
Signed-off-by: Frederic Weisbecker
---
include/linux/tick.h | 20 +++
kernel/time/tick-sched.c | 142 +--
kernel/time/tick-sched.h | 1 +
3 files changed, 158 insertions(+), 5 deletions(-)
diff --git a/include/linux/tick.h b/include/linux
k van Riel
Cc: Thomas Gleixner
Cc: Viresh Kumar
Signed-off-by: Frederic Weisbecker
---
include/linux/tick.h | 8
kernel/time/tick-sched.c | 34 ++
2 files changed, 10 insertions(+), 32 deletions(-)
diff --git a/include/linux/tick.h b/include/linux/t
: Viresh Kumar
Signed-off-by: Frederic Weisbecker
---
kernel/sched/clock.c | 5 +
kernel/time/tick-sched.c | 26 ++
2 files changed, 11 insertions(+), 20 deletions(-)
diff --git a/kernel/sched/clock.c b/kernel/sched/clock.c
index c0a2051..30e2524 100644
--- a/kernel
: Preeti U Murthy
Cc: Rik van Riel
Cc: Thomas Gleixner
Cc: Viresh Kumar
Signed-off-by: Frederic Weisbecker
---
include/linux/tick.h | 8
kernel/sched/core.c | 2 +-
kernel/time/tick-sched.c | 23 ---
3 files changed, 1 insertion(+), 32 deletions(-)
diff
process lists.
Cc: Christoph Lameter
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Preeti U Murthy
Cc: Rik van Riel
Cc: Thomas Gleixner
Cc: Viresh Kumar
Signed-off-by: Frederic Weisbecker
---
include/linux/posix-timers.h | 3 --
kernel/time/posix-cpu-timers.c | 92
r
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Preeti U Murthy
Cc: Rik van Riel
Cc: Thomas Gleixner
Cc: Viresh Kumar
Signed-off-by: Frederic Weisbecker
---
include/linux/perf_event.h | 6 --
kernel/events/core.c | 19 +--
kernel/time/tick-sched.c | 6 --
3 files chang
with 3) by checking the highest prio tasks of the
runqueue instead of its current task.
Cc: Christoph Lameter
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Preeti U Murthy
Cc: Rik van Riel
Cc: Thomas Gleixner
Cc: Viresh Kumar
Signed-off-by: Frederic Weisbecker
---
include/linux/sched.h
grated and
interact without known issue.
So lets remove that.
Reviewed-by: Rik van Riel
Cc: Christoph Lameter
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Preeti U Murthy
Cc: Rik van Riel
Cc: Thomas Gleixner
Cc: Viresh Kumar
Signed-off-by: Frederic Weisbecker
---
kernel/time/tick-sched.c | 8 +++---
On Thu, Jul 23, 2015 at 06:42:12PM +0200, Frederic Weisbecker wrote:
> Instead of providing asynchronous checks for the nohz subsystem to verify
> sched tick dependency, migrate sched to the new mask.
>
> The easiest is to recycle the current asynchronous tick dependency check
>
On Mon, Jul 13, 2015 at 03:57:57PM -0400, Chris Metcalf wrote:
> The existing nohz_full mode makes tradeoffs to minimize userspace
> interruptions while still attempting to avoid overheads in the
> kernel entry/exit path, to provide 100% kernel semantics, etc.
>
> However, some applications requir
On Tue, Jul 21, 2015 at 03:10:54PM -0400, Chris Metcalf wrote:
> >>If you're arguing that the cpu_isolated semantic is really the only
> >>one that makes sense for nohz_full, my sense is that it might be
> >>surprising to many of the folks who do nohz_full work. But, I'm happy
> >>to be wrong on t
On Fri, Jul 24, 2015 at 12:55:35PM -0400, Chris Metcalf wrote:
> On 07/23/2015 12:42 PM, Frederic Weisbecker wrote:
> >+unsigned long __tick_nohz_set_tick_dependency(enum tick_dependency_bit bit,
> >+ unsigned long *dep)
> >+{
>
On Thu, Jul 30, 2015 at 08:32:40PM -0700, Andy Lutomirski wrote:
> Code on the kprobe blacklist doesn't want unexpected int3
> exceptions. It probably doesn't want unexpected debug exceptions
> either. Be safe: disallow breakpoints in nokprobes code.
>
> On non-CONFIG_KPROBES kernels, there is n
On Thu, Jul 30, 2015 at 08:32:42PM -0700, Andy Lutomirski wrote:
> The check looked wrong, although I think it was actually safe. TASK_SIZE
> is unnecessarily small for compat tasks, and it wasn't possible to make
> a range breakpoint so large it started in user space and ended in kernel
> space.
On Tue, Aug 04, 2015 at 08:12:50PM -0400, Dave Jones wrote:
> On Tue, Aug 04, 2015 at 12:54:35AM -0400, Sasha Levin wrote:
> > On 08/03/2015 06:03 PM, Paul E. McKenney wrote:
> > >> > Ugh, that doesn't revert cleanly. Got something handy ?
> > > I do not, but perhaps either Sasha or Frederic do
On Wed, Aug 05, 2015 at 09:18:57AM -0400, Dave Jones wrote:
> On Wed, Aug 05, 2015 at 02:37:59PM +0200, Frederic Weisbecker wrote:
> > On Tue, Aug 04, 2015 at 08:12:50PM -0400, Dave Jones wrote:
> > > On Tue, Aug 04, 2015 at 12:54:35AM -0400, Sasha Levin wrote:
> > >
On Wed, Aug 05, 2015 at 07:10:57PM +0200, Oleg Nesterov wrote:
> On 07/27, Frederic Weisbecker wrote:
> >
> > Hence those two debatable changes:
> >
> > _ We would like to use generic workqueues. System unbound workqueues are
> > a very good candidate but th
On Tue, Jul 07, 2015 at 05:34:13PM +0200, Peter Zijlstra wrote:
> On Tue, Jul 07, 2015 at 03:34:22PM +0200, Frederic Weisbecker wrote:
> > Imagine the following rounds:
> >
> > utime:2 stime:2 rtime:4 --> prev->utime = 2 prev->stime = 2
> >
> > u
On Tue, Jul 07, 2015 at 06:30:30PM +0200, Oleg Nesterov wrote:
> On 07/06, Frederic Weisbecker wrote:
> >
> > The call_usermodehelper_exec_[a]sync() kernel threads are created by
> > khelper precisely because
>
> I think khelper should simply die. It doesn't make
On Wed, Jul 08, 2015 at 01:32:26AM +0200, Oleg Nesterov wrote:
> Well, sorry for noise.
>
> Let me repeat that I agree with this change, but...
>
> On 07/07, Andrew Morton wrote:
> >
> > From: Frederic Weisbecker
> > Subject: kmod: remove unecessary e
On Tue, Jul 07, 2015 at 04:07:58PM -0700, Andrew Morton wrote:
> On Mon, 6 Jul 2015 17:33:40 +0200 Frederic Weisbecker
> wrote:
>
> > There seem to be quite some confusions on the comments, likely due to
> > changes that came after them.
> >
> > Now since it
Hi,
The 2nd patch should fix the strange bug we've seen with Chris.
git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git
core/watchdog
HEAD: 5e36d90b3ccb0023ad54ac7a2381c132c6b12280
Thanks,
Frederic
---
Frederic Weisbecker (4):
smpboot: Fix m
The cpumask is allocated before threads get created. If the latter step
fails, we need to free the cpumask.
Cc: Andrew Morton
Cc: Chris Metcalf
Cc: Don Zickus
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: Ulrich Obergfell
Signed-off-by: Frederic Weisbecker
---
kernel/smpboot.c | 1 +
1 file
It makes the registration cheaper and simpler for the smpboot per-cpu
kthread users that don't need to always update the cpumask after threads
creation.
Cc: Andrew Morton
Cc: Chris Metcalf
Cc: Don Zickus
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: Ulrich Obergfell
Signed-off-by: Fre
tra
Cc: Thomas Gleixner
Cc: Ulrich Obergfell
Signed-off-by: Frederic Weisbecker
---
kernel/smpboot.c | 12 ++--
1 file changed, 2 insertions(+), 10 deletions(-)
diff --git a/kernel/smpboot.c b/kernel/smpboot.c
index 71aa90b..60aa858 100644
--- a/kernel/smpboot.c
+++ b/kernel/smpboot.c
@
lrich Obergfell
Signed-off-by: Frederic Weisbecker
---
kernel/watchdog.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/kernel/watchdog.c b/kernel/watchdog.c
index e5bb86f..d18330f 100644
--- a/kernel/watchdog.c
+++ b/kernel/watchdog.c
@@ -929,10 +929,8 @@ void _
threads but the explicit call to
set_cpus_allowed_ptr() breaks that.
So just remove it.
Cc: Rik van Riel
Cc: Oleg Nesterov
Cc: Andrew Morton
Cc: Christoph Lameter
Signed-off-by: Frederic Weisbecker
---
kernel/kmod.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/kernel/kmod.c b/kernel
nohz/kmod-v2
HEAD: 42613c237705cd6814f6ff90a2b64bd8f57700b5
Thanks,
Frederic
---
Frederic Weisbecker (5):
kmod: Bunch of internal functions renames
kmod: Use system_unbound_wq instead of khelper
kmod: Add up-to-date explanations on the purpose of each asynchronous
andle well parallel jobs.
Lets just use them.
Suggested-by: Oleg Nesterov
Cc: Rik van Riel
Cc: Oleg Nesterov
Cc: Andrew Morton
Cc: Christoph Lameter
Signed-off-by: Frederic Weisbecker
---
include/linux/kmod.h | 2 --
init/main.c | 1 -
kernel/kmod.c| 12 ++--
3 files
_exec_async
* wait_for_helper -> call_usermodehelper_exec_sync
Cc: Rik van Riel
Cc: Oleg Nesterov
Cc: Andrew Morton
Cc: Christoph Lameter
Signed-off-by: Frederic Weisbecker
---
kernel/kmod.c | 30 +-
1 file changed, 17 insertions(+), 13 deletions(-)
diff --git a/kernel/k
Cc: Oleg Nesterov
Cc: Andrew Morton
Cc: Christoph Lameter
Signed-off-by: Frederic Weisbecker
---
kernel/kmod.c | 25 +
1 file changed, 17 insertions(+), 8 deletions(-)
diff --git a/kernel/kmod.c b/kernel/kmod.c
index d8cc116ab..9ffb24c 100644
--- a/kernel/kmod.c
++
t surprise for other
works.
Cc: Rik van Riel
Cc: Oleg Nesterov
Cc: Andrew Morton
Cc: Christoph Lameter
Signed-off-by: Frederic Weisbecker
---
kernel/kmod.c | 28 +---
1 file changed, 13 insertions(+), 15 deletions(-)
diff --git a/kernel/kmod.c b/kernel/kmod.c
ind
On Tue, Aug 25, 2015 at 10:29:04AM +0200, Ingo Molnar wrote:
>
> * Frederic Weisbecker wrote:
>
> > On Mon, Aug 24, 2015 at 08:44:12AM +0200, Ingo Molnar wrote:
> > > 2)
> > >
> > > What happens if the boot CPU is offlined? (under
> > > CO
On Wed, Aug 12, 2015 at 02:22:09PM -0400, Chris Metcalf wrote:
> On 08/12/2015 12:00 PM, Frederic Weisbecker wrote:
> >>+#ifdef CONFIG_CPU_ISOLATED
> >>+void cpu_isolated_wait(void)
> >>+{
> >>+ set_current_state(TASK_INTERRUPTIBLE);
> >>+ _cp
such that we compute the task_cputime values only
> when there are per-thread timers set.
>
> Signed-off-by: Jason Low
Reviewed-by: Frederic Weisbecker
Thanks.
> ---
> kernel/time/posix-cpu-timers.c | 15 +++
> 1 files changed, 7 insertions(+), 8 deletions(-)
On Wed, Aug 26, 2015 at 10:53:35AM -0700, Linus Torvalds wrote:
> On Tue, Aug 25, 2015 at 8:17 PM, Jason Low wrote:
> >
> > This patch addresses this by having the thread_group_cputimer structure
> > maintain a boolean to signify when a thread in the group is already
> > checking for process wide
On Tue, Aug 25, 2015 at 08:17:48PM -0700, Jason Low wrote:
> It was found while running a database workload on large systems that
> significant time was spent trying to acquire the sighand lock.
>
> The issue was that whenever an itimer expired, many threads ended up
> simultaneously trying to sen
On Wed, Aug 26, 2015 at 03:53:26PM -0700, Hideaki Kimura wrote:
> Sure, let me elaborate.
>
> Executive summary:
> Yes, enabling a process-wide timer in such a large machine is not wise, but
> sometimes users/applications cannot avoid it.
>
>
> The issue was observed actually not in a database
On Wed, Aug 26, 2015 at 04:32:34PM -0700, Jason Low wrote:
> On Thu, 2015-08-27 at 00:56 +0200, Frederic Weisbecker wrote:
> > On Tue, Aug 25, 2015 at 08:17:48PM -0700, Jason Low wrote:
> > > It was found while running a database workload on large systems that
> > >
On Wed, Aug 26, 2015 at 04:45:44PM -0700, Hideaki Kimura wrote:
> I totally agree that this is not a perfect solution. If there are 10x more
> cores and sockets, just the atomic fetch_add might be too expensive.
>
> However, it's comparatively/realistically the best thing we can do without
> any d
On Thu, Aug 27, 2015 at 05:09:21PM +0200, Thomas Gleixner wrote:
> On Thu, 27 Aug 2015, Steven Rostedt wrote:
> > On Thu, 27 Aug 2015 15:18:49 +0200
> > Frederic Weisbecker wrote:
> >
> > > On Wed, Aug 26, 2015 at 04:45:44PM -0700, Hideaki Kimura wrote:
> > &g
On Thu, Aug 27, 2015 at 01:29:50PM -0700, Jason Low wrote:
> On Thu, 2015-08-27 at 14:53 +0200, Frederic Weisbecker wrote:
> > Sure, like:
> >
> > #define CPUTIMER_RUNNING 0x1
> > #define CPUTIMER_CHECKING 0x2
> >
> > struct thread_group_cputim
On Tue, Jul 28, 2015 at 02:01:14PM -0400, Tejun Heo wrote:
> Hello, Frederic.
>
> On Mon, Jul 27, 2015 at 11:05:41PM +0200, Frederic Weisbecker wrote:
> > > IMHO, system_wq should be fine and if it isn't turning off numa
> > > affinity or raising max work
On Fri, Jul 24, 2015 at 12:56:42PM -0400, Chris Metcalf wrote:
> On 07/23/2015 12:42 PM, Frederic Weisbecker wrote:
> >+static inline void sched_update_tick_dependency(struct rq *rq)
> >+{
> >+int cpu;
> >+
> >+if (!tick_nohz_full_enabled())
> &g
On Fri, Jul 24, 2015 at 12:57:24PM -0400, Chris Metcalf wrote:
> On 07/23/2015 12:42 PM, Frederic Weisbecker wrote:
> >+static void cpu_timer_list_dequeue(struct cpu_timer_list *t)
> >+{
> >+if (!list_empty(&t->entry))
> >+cpu_timer_dec_tick_depe
On Wed, Jul 29, 2015 at 01:24:16PM -0400, Chris Metcalf wrote:
> On 07/29/2015 09:23 AM, Frederic Weisbecker wrote:
> >>At a higher level, is the posix-cpu-timers code here really providing the
> >>>right semantics? It seems like before, the code was checking a struct
me needless.
* Restart nohz full tick from irq exit. A simplification and a
preparation for future optimization on scheduler kick to nohz full.
* Simple code cleanups.
* Tile driver isolation enhancement on top of nohz.
Thanks,
Frederic
---
Frederic Weisbecker (7):
jiffies: Remove HZ >
On Thu, Jul 30, 2015 at 10:31:47AM -0400, Luiz Capitulino wrote:
> On Thu, 30 Jul 2015 02:44:45 +0200
> Frederic Weisbecker wrote:
> > On Wed, Jul 29, 2015 at 01:24:16PM -0400, Chris Metcalf wrote:
> > > I really worry about this! The vision EZchip offers our customers is
&g
On Thu, Jul 30, 2015 at 03:35:06PM -0400, Chris Metcalf wrote:
> On 07/29/2015 08:44 PM, Frederic Weisbecker wrote:
> >I see. But note that installing a posix cpu timer ends up triggering an
> >IPI to all nohz full CPUs. That's how nohz full has always behaved.
> >So use
at we have
enough system unbound workers to handle lots of parallel usermodehelper
jobs.
Cc: Rik van Riel
Cc: Oleg Nesterov
Cc: Andrew Morton
Cc: Christoph Lameter
Cc: Tejun Heo
Signed-off-by: Frederic Weisbecker
---
kernel/kmod.c | 44
1 file c
_exec_async
* wait_for_helper -> call_usermodehelper_exec_sync
Cc: Rik van Riel
Cc: Oleg Nesterov
Cc: Andrew Morton
Cc: Christoph Lameter
Cc: Tejun Heo
Signed-off-by: Frederic Weisbecker
---
kernel/kmod.c | 30 +-
1 file changed, 17 insertions(+), 13 deletions(-)
diff
wide affine.
---
git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git
nohz/kmod-v3
HEAD: 470ed6f10191864d28d2c8f4fd8a349ef58f427b
Thanks,
Frederic
---
Frederic Weisbecker (5):
kmod: Bunch of internal functions renames
kmod: Remove unecessary explicit
Cc: Oleg Nesterov
Cc: Andrew Morton
Cc: Christoph Lameter
Cc: Tejun Heo
Signed-off-by: Frederic Weisbecker
---
kernel/kmod.c | 32
1 file changed, 24 insertions(+), 8 deletions(-)
diff --git a/kernel/kmod.c b/kernel/kmod.c
index 97be0cf..7833041 100644
--
s who
rely on workqueue affinity tuning.
Cc: Rik van Riel
Cc: Oleg Nesterov
Cc: Andrew Morton
Cc: Christoph Lameter
Cc: Tejun Heo
Signed-off-by: Frederic Weisbecker
---
kernel/kmod.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/kernel/kmod.c b/kernel/kmod.c
index 4682e91..97be0cf 1
queues assuming
that a node is sufficient to handle several parallel usermodehelper
requests.
Cc: Rik van Riel
Cc: Oleg Nesterov
Cc: Andrew Morton
Cc: Christoph Lameter
Cc: Tejun Heo
Signed-off-by: Frederic Weisbecker
---
include/linux/kmod.h | 2 --
init/main.c | 1 -
kernel/kmo
On Mon, Jul 27, 2015 at 02:48:40PM -0400, Tejun Heo wrote:
> On Mon, Jul 27, 2015 at 06:27:15PM +0200, Frederic Weisbecker wrote:
> > Hence those two debatable changes:
> >
> > _ We would like to use generic workqueues. System unbound workqueues are
> > a very good
2015-08-17 6:31 GMT+02:00 Andi Kleen :
>
> Modern Intel Core CPUs (5th and 6th generation) have a Intel Processor Trace
> (PT) feature
> to trace branch execution with low overhead. This is useful for performance
> analysis and debugging.
>
> simple-pt is a simple standalone driver and decoder to
Just small clarifications and a tiny simplification.
Thanks.
Frederic Weisbecker (2):
hrtimer: Simplify get_target_base() returning current base
hrtimer: Unconfuse a bit switch_hrtimer_base
kernel/time/hrtimer.c | 22 --
1 file changed, 12 insertions(+), 10 deletions
The variable called "this_base" is confusing because its name suggests
it's of "struct hrtimer_clock_base" type, along with "base" and "new_base"
which doesn't help understanding this complicated function.
Make its name clearer and fix the mislead
Instead of fetching again the current cpu base, just take it from the
parameter.
Signed-off-by: Frederic Weisbecker
---
kernel/time/hrtimer.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c
index 55575d4..f9eb21b 100644
--- a
On Tue, Aug 18, 2015 at 12:11:59PM -0700, Andy Lutomirski wrote:
> This fixes a couple minor holes if we took an IRQ very early in syscall
> processing:
>
> - We could enter the IRQ with CONTEXT_USER. Everything worked (RCU
>was fine), but we could warn if all the debugging options were
>
2801 - 2900 of 4589 matches
Mail list logo
