Re: [PATCH v2 RESEND 0/5] sched/vtime: vtime.h headers cleanup

2024-04-17 Thread Frederic Weisbecker
Le Wed, Apr 10, 2024 at 05:09:43PM +0200, Alexander Gordeev a écrit : > Hi All, > > There are no changes since the last post, just a re-send. > > v2: > - patch 4: commit message reworded (Heiko) > - patch 5: vtime.h is removed from Kbuild scripts (PowerPC only) (Heiko) > > v1: > Please find a

Re: [PATCH 5/5] sched/vtime: do not include header

2024-02-07 Thread Frederic Weisbecker
Le Wed, Feb 07, 2024 at 03:12:57PM +0100, Alexander Gordeev a écrit : > On Wed, Feb 07, 2024 at 12:30:08AM +0100, Frederic Weisbecker wrote: > > Reviewed-by: Frederic Weisbecker > > Thank you for the review, Frederic! > > The Heiko comment is valid and I would

Re: [PATCH 5/5] sched/vtime: do not include header

2024-02-06 Thread Frederic Weisbecker
Le Sun, Jan 28, 2024 at 08:58:54PM +0100, Alexander Gordeev a écrit : > There is no architecture-specific code or data left > that generic needs to know about. > Thus, avoid the inclusion of header. > > Signed-off-by: Alexander Gordeev Reviewed-by: Frederic Weisbecker

Re: [PATCH 3/5] s390/vtime: remove unused __ARCH_HAS_VTIME_TASK_SWITCH leftover

2024-02-06 Thread Frederic Weisbecker
Le Sun, Jan 28, 2024 at 08:58:52PM +0100, Alexander Gordeev a écrit : > __ARCH_HAS_VTIME_TASK_SWITCH macro is not used anymore. > > Signed-off-by: Alexander Gordeev Reviewed-by: Frederic Weisbecker > --- > arch/s390/include/asm/vtime.h | 2 -- > 1 file changed, 2 dele

Re: [PATCH 2/5] sched/vtime: get rid of generic vtime_task_switch() implementation

2024-02-06 Thread Frederic Weisbecker
ation to PowerPC. > > Signed-off-by: Alexander Gordeev Reviewed-by: Frederic Weisbecker

Re: [PATCH 1/5] sched/vtime: remove confusing arch_vtime_task_switch() declaration

2024-02-06 Thread Frederic Weisbecker
iant. Remove it. > > Signed-off-by: Alexander Gordeev Reviewed-by: Frederic Weisbecker

Re: [PATCH 3/3] mm/mmu_gather: send tlb_remove_table_smp_sync IPI only to CPUs in kernel mode

2023-04-05 Thread Frederic Weisbecker
On Wed, Apr 05, 2023 at 02:05:13PM +0200, Frederic Weisbecker wrote: > On Wed, Apr 05, 2023 at 01:41:48PM +0200, Peter Zijlstra wrote: > 1) It has the advantage to check context tracking _after_ the llist_add(), so >it really can't be misused ordering-wise. > > 2) The IPI cal

Re: [PATCH 3/3] mm/mmu_gather: send tlb_remove_table_smp_sync IPI only to CPUs in kernel mode

2023-04-05 Thread Frederic Weisbecker
On Wed, Apr 05, 2023 at 01:41:48PM +0200, Peter Zijlstra wrote: > On Wed, Apr 05, 2023 at 01:10:07PM +0200, Frederic Weisbecker wrote: > > On Wed, Apr 05, 2023 at 12:44:04PM +0200, Frederic Weisbecker wrote: > > > On Tue, Apr 04, 2023 at 04:42:24PM +0300, Yair Podemsky wrote: &

Re: [PATCH 3/3] mm/mmu_gather: send tlb_remove_table_smp_sync IPI only to CPUs in kernel mode

2023-04-05 Thread Frederic Weisbecker
On Wed, Apr 05, 2023 at 12:44:04PM +0200, Frederic Weisbecker wrote: > On Tue, Apr 04, 2023 at 04:42:24PM +0300, Yair Podemsky wrote: > > + int state = atomic_read(>state); > > + /* will return true only for cpus in kernel space */ > > + return state & CT_

Re: [PATCH 3/3] mm/mmu_gather: send tlb_remove_table_smp_sync IPI only to CPUs in kernel mode

2023-04-05 Thread Frederic Weisbecker
On Tue, Apr 04, 2023 at 04:42:24PM +0300, Yair Podemsky wrote: > @@ -191,6 +192,20 @@ static void tlb_remove_table_smp_sync(void *arg) > /* Simply deliver the interrupt */ > } > > + > +#ifdef CONFIG_CONTEXT_TRACKING > +static bool cpu_in_kernel(int cpu, void *info) > +{ > + struct

Re: [PATCH linux-next][RFC]torture: avoid offline tick_do_timer_cpu

2022-11-23 Thread Frederic Weisbecker
On Mon, Nov 21, 2022 at 11:51:40AM +0800, Zhouyi Zhou wrote: > During CPU-hotplug torture (CONFIG_NO_HZ_FULL=y), if we try to > offline tick_do_timer_cpu, the operation will fail because in > function tick_nohz_cpu_down: > ``` > if (tick_nohz_full_running && tick_do_timer_cpu == cpu) >

Re: [PATCH linux-next][RFC]torture: avoid offline tick_do_timer_cpu

2022-11-23 Thread Frederic Weisbecker
On Mon, Nov 21, 2022 at 05:37:54PM -0800, Paul E. McKenney wrote: > On Mon, Nov 21, 2022 at 11:51:40AM +0800, Zhouyi Zhou wrote: > > @@ -358,7 +359,16 @@ torture_onoff(void *arg) > > schedule_timeout_interruptible(HZ / 10); > > continue; > > } >

Re: [PATCH v2 00/44] cpuidle,rcu: Clean up the mess

2022-09-20 Thread Frederic Weisbecker
- ubsan/kasan fixes > - intel_idle module-param for testing > - a bunch of extra __always_inline, because compilers are silly. Except for those I have already tagged as Reviewed: Acked-by: Frederic Weisbecker Thanks for the hard work!

Re: [PATCH v2 11/44] cpuidle,omap4: Push RCU-idle into driver

2022-09-20 Thread Frederic Weisbecker
-by: Tony Lindgren Reviewed-by: Frederic Weisbecker

Re: [PATCH v2 03/44] cpuidle/poll: Ensure IRQ state is invariant

2022-09-20 Thread Frederic Weisbecker
On Tue, Sep 20, 2022 at 10:57:00AM +0200, Peter Zijlstra wrote: > On Mon, Sep 19, 2022 at 03:19:27PM +0200, Frederic Weisbecker wrote: > > On Mon, Sep 19, 2022 at 11:59:42AM +0200, Peter Zijlstra wrote: > > > cpuidle_state::enter() methods should be IRQ invariant > >

Re: [PATCH v2 08/44] cpuidle,imx6: Push RCU-idle into driver

2022-09-20 Thread Frederic Weisbecker
On Tue, Sep 20, 2022 at 10:58:59AM +0200, Peter Zijlstra wrote: > On Mon, Sep 19, 2022 at 04:21:23PM +0200, Frederic Weisbecker wrote: > > On Mon, Sep 19, 2022 at 11:59:47AM +0200, Peter Zijlstra wrote: > > > Doing RCU-idle outside the driver, only to then temporarily ena

Re: [PATCH v2 09/44] cpuidle,omap3: Push RCU-idle into driver

2022-09-20 Thread Frederic Weisbecker
On Mon, Sep 19, 2022 at 05:19:05PM +0200, Peter Zijlstra wrote: > On Mon, Sep 19, 2022 at 04:31:42PM +0200, Frederic Weisbecker wrote: > > On Mon, Sep 19, 2022 at 11:59:48AM +0200, Peter Zijlstra wrote: > > > Doing RCU-idle outside the driver, only to then teporarily enable it

Re: [PATCH v2 08/44] cpuidle,imx6: Push RCU-idle into driver

2022-09-19 Thread Frederic Weisbecker
On Mon, Sep 19, 2022 at 05:03:04PM +0200, Peter Zijlstra wrote: > On Mon, Sep 19, 2022 at 04:49:41PM +0200, Frederic Weisbecker wrote: > > On Mon, Sep 19, 2022 at 11:59:47AM +0200, Peter Zijlstra wrote: > > > Doing RCU-idle outside the driver, only to then temporarily ena

Re: [PATCH v2 08/44] cpuidle,imx6: Push RCU-idle into driver

2022-09-19 Thread Frederic Weisbecker
On Mon, Sep 19, 2022 at 11:59:47AM +0200, Peter Zijlstra wrote: > Doing RCU-idle outside the driver, only to then temporarily enable it > again, at least twice, before going idle is daft. > > Signed-off-by: Peter Zijlstra (Intel) > --- > arch/arm/mach-imx/cpuidle-imx6sx.c |5 - > 1 file

Re: [PATCH v2 09/44] cpuidle,omap3: Push RCU-idle into driver

2022-09-19 Thread Frederic Weisbecker
w with the cpu_pm_*() informations that makes sense: Reviewed-by: Frederic Weisbecker

Re: [PATCH v2 10/44] cpuidle,armada: Push RCU-idle into driver

2022-09-19 Thread Frederic Weisbecker
c > @@ -36,7 +36,10 @@ static int mvebu_v7_enter_idle(struct cp > if (drv->states[index].flags & MVEBU_V7_FLAG_DEEP_IDLE) > deepidle = true; > > + ct_idle_enter(); > ret = mvebu_v7_cpu_suspend(deepidle); > + ct_idle_exit(); And then yes of course: Reviewed-by: Frederic Weisbecker

Re: [PATCH v2 09/44] cpuidle,omap3: Push RCU-idle into driver

2022-09-19 Thread Frederic Weisbecker
On Mon, Sep 19, 2022 at 11:59:48AM +0200, Peter Zijlstra wrote: > Doing RCU-idle outside the driver, only to then teporarily enable it > again before going idle is daft. That doesn't tell where those calls are. Thanks.

Re: [PATCH v2 08/44] cpuidle,imx6: Push RCU-idle into driver

2022-09-19 Thread Frederic Weisbecker
On Mon, Sep 19, 2022 at 11:59:47AM +0200, Peter Zijlstra wrote: > Doing RCU-idle outside the driver, only to then temporarily enable it > again, at least twice, before going idle is daft. Hmm, what ends up calling RCU_IDLE() here? Also what about cpu_do_idle()? Thanks. > > Signed-off-by: Peter

Re: [PATCH v2 07/44] cpuidle,psci: Push RCU-idle into driver

2022-09-19 Thread Frederic Weisbecker
On Mon, Sep 19, 2022 at 11:59:46AM +0200, Peter Zijlstra wrote: > Doing RCU-idle outside the driver, only to then temporarily enable it > again, at least twice, before going idle is daft. > > Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Frederic Weisbecker

Re: [PATCH v2 06/44] cpuidle,tegra: Push RCU-idle into driver

2022-09-19 Thread Frederic Weisbecker
On Mon, Sep 19, 2022 at 11:59:45AM +0200, Peter Zijlstra wrote: > Doing RCU-idle outside the driver, only to then temporarily enable it > again, at least twice, before going idle is daft. > > Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Frederic Weisbecker

Re: [PATCH v2 05/44] cpuidle,riscv: Push RCU-idle into driver

2022-09-19 Thread Frederic Weisbecker
On Mon, Sep 19, 2022 at 11:59:44AM +0200, Peter Zijlstra wrote: > Doing RCU-idle outside the driver, only to then temporarily enable it > again, at least twice, before going idle is daft. > > Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Frederic Weisbecker

Re: [PATCH v2 03/44] cpuidle/poll: Ensure IRQ state is invariant

2022-09-19 Thread Frederic Weisbecker
On Mon, Sep 19, 2022 at 11:59:42AM +0200, Peter Zijlstra wrote: > cpuidle_state::enter() methods should be IRQ invariant Got a bit confused with the invariant thing since the first chunck I see in this patch is a conversion to an non-traceable local_irq_enable(). Maybe just add a short mention

Re: ppc64le: `NOHZ tick-stop error: Non-RCU local softirq work is pending, handler #20!!!` when turning off SMT

2022-02-08 Thread Frederic Weisbecker
On Tue, Feb 08, 2022 at 08:32:37AM +0100, Paul Menzel wrote: > Dear Linux folks, > > > On the POWER8 server IBM S822LC running Ubuntu 21.10, Linux 5.17-rc1+ built > with > > $ grep HZ /boot/config-5.17.0-rc1+ > CONFIG_NO_HZ_COMMON=y > # CONFIG_HZ_PERIODIC is not set >

Re: Endless soft-lockups for compiling workload since next-20200519

2020-05-25 Thread Frederic Weisbecker
On Mon, May 25, 2020 at 03:21:05PM +0200, Peter Zijlstra wrote: > @@ -2320,7 +2304,7 @@ static void ttwu_queue_remote(struct task_struct *p, > int cpu, int wake_flags) > > if (llist_add(>wake_entry, >wake_list)) { > if (!set_nr_if_polling(rq->idle)) > -

Re: Endless soft-lockups for compiling workload since next-20200519

2020-05-21 Thread Frederic Weisbecker
On Thu, May 21, 2020 at 01:00:27PM +0200, Peter Zijlstra wrote: > On Thu, May 21, 2020 at 12:49:37PM +0200, Peter Zijlstra wrote: > > On Thu, May 21, 2020 at 11:39:39AM +0200, Peter Zijlstra wrote: > > > On Thu, May 21, 2020 at 02:40:36AM +0200, Frederi

Re: Endless soft-lockups for compiling workload since next-20200519

2020-05-20 Thread Frederic Weisbecker
On Wed, May 20, 2020 at 02:50:56PM +0200, Peter Zijlstra wrote: > On Tue, May 19, 2020 at 11:58:17PM -0400, Qian Cai wrote: > > Just a head up. Repeatedly compiling kernels for a while would trigger > > endless soft-lockups since next-20200519 on both x86_64 and powerpc. > > .config are in, > >

Re: [Qemu-ppc] pseries on qemu-system-ppc64le crashes in doorbell_core_ipi()

2019-04-05 Thread Frederic Weisbecker
ist_add(>llnode, _cpu(raised_list, cpu))) > > + arch_send_call_function_single_ipi(cpu); > > + } else > > + __irq_work_queue(work); Also perhaps rename __irq_work_queue() to irq_work_queue_local() to make it instantly clearer to reviewers. Other than those cosmetic changes, Reviewed-by: Frederic Weisbecker Thanks.

Re: [BUG][next-20170606][bisected 411fe24e6b] WARNING: CPU: 10 PID: 0 at kernel/time/tick-sched.c:791

2017-06-09 Thread Frederic Weisbecker
res(>sched_timer)); > } > > Trace logs: > [22934.302780] [ cut here ] > [22934.302787] WARNING: CPU: 10 PID: 0 at kernel/time/tick-sched.c:791 > __tick_nohz_idle_enter+0x2e8/0x570 Hi Abdul, Thanks for reporting. I've cooked a fix, any chance you c

Re: [PATCH] powerpc: Remove leftover cputime_to_nsecs call causing build error

2017-02-22 Thread Frederic Weisbecker
On Thu, Feb 23, 2017 at 08:34:15AM +1100, Michael Ellerman wrote: > Frederic Weisbecker <fweis...@gmail.com> writes: > > > This type conversion is a leftover that got ignored during the kcpustat > > conversion to nanosecs, resulting in build breakage with config having

Re: [PowerPC] 4.10.0 fails to build on BE config

2017-02-21 Thread Frederic Weisbecker
On Tue, Feb 21, 2017 at 12:55:35PM +0530, abdul wrote: > Hi, > > Today's mainline build, breaks on Power6 and Power7 (all BE config) with > these build errors > > arch/powerpc/kernel/time.c: In function ‘running_clock’: > arch/powerpc/kernel/time.c:712:2: error: implicit declaration of function

[PATCH] powerpc: Remove leftover cputime_to_nsecs call causing build error

2017-02-21 Thread Frederic Weisbecker
lerman.id.au> Cc: Benjamin Herrenschmidt <b...@kernel.crashing.org> Cc: Paul Mackerras <pau...@samba.org> Cc: Oliver O'Halloran <ooh...@gmail.com> Cc: linuxppc-dev@lists.ozlabs.org Signed-off-by: Frederic Weisbecker <fweis...@gmail.com> --- arch/powerpc/kernel/time.c |

Re: [PATCH 0/4] cputime: some optimizations and cleanups

2016-11-09 Thread Frederic Weisbecker
-- > kernel/time/posix-cpu-timers.c|4 +- > 14 files changed, 73 insertions(+), 133 deletions(-) > Excellent patchset! Thanks a lot Stanislaw! Acked-by: Frederic Weisbecker <fweis...@gmail.com>

Re: [PATCH] powerpc: re-enable dynticks

2015-02-22 Thread Frederic Weisbecker
Hi Ben, 2015-02-16 5:06 GMT+01:00 Benjamin Herrenschmidt b...@kernel.crashing.org: On Mon, 2015-02-16 at 11:08 +1100, Michael Ellerman wrote: On Fri, 2015-02-13 at 13:38 -0600, Paul Clarke wrote: implement arch_irq_work_has_interrupt() for powerpc Commit 9b01f5bf3 introduced a dependency

Re: perf events ring buffer memory barrier on powerpc

2013-10-28 Thread Frederic Weisbecker
2013/10/25 Peter Zijlstra pet...@infradead.org: On Wed, Oct 23, 2013 at 03:19:51PM +0100, Frederic Weisbecker wrote: I would argue for: READ -data_tail READ -data_head smp_rmb() (A) smp_rmb() (C) WRITE $data

Re: perf events ring buffer memory barrier on powerpc

2013-10-23 Thread Frederic Weisbecker
On Wed, Oct 23, 2013 at 10:54:54AM +1100, Michael Neuling wrote: Frederic, In the perf ring buffer code we have this in perf_output_get_handle(): if (!local_dec_and_test(rb-nest)) goto out; /* * Publish the known good head. Rely on the full barrier

Re: perf events ring buffer memory barrier on powerpc

2013-10-23 Thread Frederic Weisbecker
2013/10/23 Frederic Weisbecker fweis...@gmail.com: On Wed, Oct 23, 2013 at 10:54:54AM +1100, Michael Neuling wrote: Frederic, In the perf ring buffer code we have this in perf_output_get_handle(): if (!local_dec_and_test(rb-nest)) goto out; /* * Publish

Re: linux-next: build failure after merge of the akpm tree

2013-10-02 Thread Frederic Weisbecker
On Wed, Sep 25, 2013 at 02:43:28PM -0700, Andrew Morton wrote: On Wed, 25 Sep 2013 14:32:14 -0700 (PDT) Hugh Dickins hu...@google.com wrote: On Wed, 25 Sep 2013, Andrew Morton wrote: On Wed, 25 Sep 2013 11:06:43 +1000 Stephen Rothwell s...@canb.auug.org.au wrote: Hi Andrew,

Re: [RFC PATCH 4/5] cpuidle/ppc: CPU goes tickless if there are no arch-specific constraints

2013-07-25 Thread Frederic Weisbecker
On Thu, Jul 25, 2013 at 02:33:02PM +0530, Preeti U Murthy wrote: In the current design of timer offload framework, the broadcast cpu should *not* go into tickless idle so as to avoid missed wakeups on CPUs in deep idle states. Since we prevent the CPUs entering deep idle states from

Re: [RFC PATCH v3 0/5] powerpc: Support context tracking for Power pSeries

2013-05-29 Thread Frederic Weisbecker
On Mon, May 13, 2013 at 04:03:13PM +0800, Li Zhong wrote: On Mon, 2013-05-13 at 15:51 +1000, Benjamin Herrenschmidt wrote: On Mon, 2013-05-13 at 13:21 +0800, Li Zhong wrote: These patches try to support context tracking for Power arch, beginning with 64-bit pSeries. The codes are

Re: [RFC PATCH v3 0/5] powerpc: Support context tracking for Power pSeries

2013-05-29 Thread Frederic Weisbecker
On Mon, May 13, 2013 at 06:59:23PM +1000, Benjamin Herrenschmidt wrote: On Mon, 2013-05-13 at 16:03 +0800, Li Zhong wrote: To my understanding, it is used to enable RCU user extended quiescent state, so RCU on that cpu doesn't need scheduler ticks. And together with some other

Re: [RFC PATCH 1/5] powerpc: Syscall hooks for context tracking subsystem

2013-02-10 Thread Frederic Weisbecker
-by: Frederic Weisbecker fweis...@gmail.com --- arch/powerpc/include/asm/thread_info.h |7 +-- arch/powerpc/kernel/ptrace.c |5 + 2 files changed, 10 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/include/asm/thread_info.h b/arch/powerpc/include/asm

Re: [RFC PATCH 2/5] powerpc: Exception hooks for context tracking subsystem

2013-02-10 Thread Frederic Weisbecker
2013/2/1 Li Zhong zh...@linux.vnet.ibm.com: This is the exception hooks for context tracking subsystem, including data access, program check, single step, instruction breakpoint, machine check, alignment, fp unavailable, altivec assist, unknown exception, whose handlers might use RCU. This

Re: [PATCH 4/8] cputime: Generic on-demand virtual cputime accounting

2013-02-08 Thread Frederic Weisbecker
2013/2/8 Stephen Rothwell s...@canb.auug.org.au: Hi Frederic, On Fri, 8 Feb 2013 14:07:49 +1100 Stephen Rothwell s...@canb.auug.org.au wrote: This patch has the side effect of changing the default configurations: (This is PowerPC pseries_defconfig before/after this patch) @@ -119,8

Re: [RFC PATCH 1/5] powerpc: Syscall hooks for context tracking subsystem

2013-02-07 Thread Frederic Weisbecker
2013/2/7 Li Zhong zh...@linux.vnet.ibm.com: On Thu, 2013-02-07 at 01:29 +0100, Frederic Weisbecker wrote: In x86-64, schedule_user() and do_notify_resume() can be called before syscall_trace_leave(). As a result we may be entering syscall_trace_leave() in user mode (from a context tracking POV

Re: [RFC PATCH 1/5] powerpc: Syscall hooks for context tracking subsystem

2013-02-06 Thread Frederic Weisbecker
2013/2/1 Li Zhong zh...@linux.vnet.ibm.com: This is the syscall slow path hooks for context tracking subsystem, corresponding to [PATCH] x86: Syscall hooks for userspace RCU extended QS commit bf5a3c13b939813d28ce26c01425054c740d6731 TIF_MEMDIE is moved to the second 16-bits (with value

Re: powerpc/perf: hw breakpoints return ENOSPC

2012-09-27 Thread Frederic Weisbecker
2012/9/25 Michael Neuling mi...@neuling.org: Michael Neuling mi...@neuling.org wrote: Frederic Weisbecker fweis...@gmail.com wrote: On Thu, Aug 16, 2012 at 02:23:54PM +1000, Michael Neuling wrote: Hi, I've been trying to get hardware breakpoints with perf to work on POWER7

Re: powerpc/perf: hw breakpoints return ENOSPC

2012-08-17 Thread Frederic Weisbecker
On Thu, Aug 16, 2012 at 02:23:54PM +1000, Michael Neuling wrote: Hi, I've been trying to get hardware breakpoints with perf to work on POWER7 but I'm getting the following: % perf record -e mem:0x1000 true Error: sys_perf_event_open() syscall returned with 28 (No space left on

Re: [PATCH 2/6] hw_breakpoints: Migrate breakpoint conditional build under new config

2011-07-05 Thread Frederic Weisbecker
On Mon, Jul 04, 2011 at 11:14:16PM +0530, K.Prasad wrote: On Mon, Jul 04, 2011 at 03:29:14PM +0200, Frederic Weisbecker wrote: On Mon, Jul 04, 2011 at 06:57:46PM +0530, K.Prasad wrote: On Tue, May 24, 2011 at 11:52:23PM +0200, Frederic Weisbecker wrote: Migrate conditional hw_breakpoint

Re: [PATCH 2/6] hw_breakpoints: Migrate breakpoint conditional build under new config

2011-07-04 Thread Frederic Weisbecker
On Mon, Jul 04, 2011 at 06:57:46PM +0530, K.Prasad wrote: On Tue, May 24, 2011 at 11:52:23PM +0200, Frederic Weisbecker wrote: Migrate conditional hw_breakpoint code compilation under the new config to prepare for letting the user chose whether or not to build this feature Signed-off

Re: [PATCH 4/6] hw_breakpoints: Breakpoints arch ability don't need perf events

2011-07-04 Thread Frederic Weisbecker
On Mon, Jul 04, 2011 at 07:02:23PM +0530, K.Prasad wrote: On Tue, May 24, 2011 at 11:52:25PM +0200, Frederic Weisbecker wrote: The breakpoint support ability in an arch is not related to the fact perf events is built or not. HAVE_HW_BREAKPOINT only shows an ability so this dependency makes

[PATCH v2] hw_breakpoint: Let the user choose not to build it (and perf too)

2011-05-24 Thread Frederic Weisbecker
Mostly just a rebase against latest upstream updates and acks from Will Deacon added In this second version. Please tell me if you are ok with this set. Thanks. --- Frederic Weisbecker (6): hw_breakpoints: Split hardware breakpoints config hw_breakpoints: Migrate breakpoint

[PATCH 1/6] hw_breakpoints: Split hardware breakpoints config

2011-05-24 Thread Frederic Weisbecker
this new modularity. Signed-off-by: Frederic Weisbecker fweis...@gmail.com Cc: Ingo Molnar mi...@elte.hu Cc: Peter Zijlstra a.p.zijls...@chello.nl Cc: Will Deacon will.dea...@arm.com Cc: Prasad pra...@linux.vnet.ibm.com Cc: Paul Mundt let...@linux-sh.org --- arch/sh/Kconfig |1 + arch/x86

[PATCH 4/6] hw_breakpoints: Breakpoints arch ability don't need perf events

2011-05-24 Thread Frederic Weisbecker
-by: Frederic Weisbecker fweis...@gmail.com Cc: Ingo Molnar mi...@elte.hu Cc: Peter Zijlstra a.p.zijls...@chello.nl Cc: Will Deacon will.dea...@arm.com Cc: Prasad pra...@linux.vnet.ibm.com Cc: Paul Mundt let...@linux-sh.org --- arch/Kconfig |1 - 1 files changed, 0 insertions(+), 1 deletions

[PATCH 2/6] hw_breakpoints: Migrate breakpoint conditional build under new config

2011-05-24 Thread Frederic Weisbecker
Migrate conditional hw_breakpoint code compilation under the new config to prepare for letting the user chose whether or not to build this feature Signed-off-by: Frederic Weisbecker fweis...@gmail.com Acked-by: Will Deacon will.dea...@arm.com Cc: Ingo Molnar mi...@elte.hu Cc: Peter Zijlstra

[PATCH 5/6] hw_breakpoints: Only force perf events if breakpoints are selected

2011-05-24 Thread Frederic Weisbecker
Previously, arch were forced to always build perf events if they supported hw_breakpoints. Now that the user can choose not to build hw_breakpoints, let only force perf events if hw_breakpoints are selected. Signed-off-by: Frederic Weisbecker fweis...@gmail.com Cc: Ingo Molnar mi...@elte.hu Cc

[PATCH 3/6] x86: Allow the user not to build hw_breakpoints

2011-05-24 Thread Frederic Weisbecker
So that hw_breakpoints and perf can be not built on specific embedded systems. Signed-off-by: Frederic Weisbecker fweis...@gmail.com Cc: Ingo Molnar mi...@elte.hu Cc: Peter Zijlstra a.p.zijls...@chello.nl Cc: Jason Wessel jason.wes...@windriver.com Cc: H. Peter Anvin h...@zytor.com Cc: Thomas

[PATCH 6/6] hw_breakpoints: Drop remaining misplaced dependency on perf

2011-05-24 Thread Frederic Weisbecker
Powerpc and Arm select breakpoint support ability only if Perf is built. This is not necessary anymore now that we enable perf once breakpoints support is selected. Signed-off-by: Frederic Weisbecker fweis...@gmail.com Acked-by: Will Deacon will.dea...@arm.com Cc: Ingo Molnar mi...@elte.hu Cc

Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering

2011-05-12 Thread Frederic Weisbecker
On Thu, May 12, 2011 at 09:48:50AM +0200, Ingo Molnar wrote: To restrict execution to system calls. Two observations: 1) We already have a specific ABI for this: you can set filters for events via an event fd. Why not extend that mechanism instead and improve *both* your

[tip:perf/urgent] hw_breakpoints, powerpc: Fix CONFIG_HAVE_HW_BREAKPOINT off-case in ptrace_set_debugreg()

2011-05-06 Thread tip-bot for Frederic Weisbecker
Commit-ID: 925f83c085e1bb08435556c5b4844a60de002e31 Gitweb: http://git.kernel.org/tip/925f83c085e1bb08435556c5b4844a60de002e31 Author: Frederic Weisbecker fweis...@gmail.com AuthorDate: Fri, 6 May 2011 01:53:18 +0200 Committer: Ingo Molnar mi...@elte.hu CommitDate: Fri, 6 May 2011 11:24

[PATCH] powerpc, hw_breakpoints: Fix CONFIG_HAVE_HW_BREAKPOINT off-case in ptrace_set_debugreg

2011-05-05 Thread Frederic Weisbecker
'ptrace_get_breakpoints' make[2]: *** [arch/powerpc/kernel/ptrace.o] Error 1 make[1]: *** [arch/powerpc/kernel] Error 2 make: *** [sub-make] Error 2 Reported-by: Ingo Molnar mi...@elte.hu Signed-off-by: Frederic Weisbecker fweis...@gmail.com Cc: Prasad pra...@linux.vnet.ibm.com Cc: v2.6.33.. sta...@kernel.org --- arch

[PATCH 2/6] hw_breakpoints: Migrate breakpoint conditional build under new config

2011-04-27 Thread Frederic Weisbecker
Migrate conditional hw_breakpoint code compilation under the new config to prepare for letting the user chose whether or not to build this feature Signed-off-by: Frederic Weisbecker fweis...@gmail.com Cc: Ingo Molnar mi...@elte.hu Cc: Peter Zijlstra a.p.zijls...@chello.nl Cc: Will Deacon will.dea

[PATCH 6/6] hw_breakpoints: Drop remaining misplaced dependency on perf

2011-04-27 Thread Frederic Weisbecker
Powerpc and Arm select breakpoint support ability only if Perf is built. This is not necessary anymore now that we enable perf once breakpoints support is selected. Signed-off-by: Frederic Weisbecker fweis...@gmail.com Cc: Ingo Molnar mi...@elte.hu Cc: Peter Zijlstra a.p.zijls...@chello.nl Cc

[PATCH 3/5] powerpc, hw_breakpoints: Fix racy access to ptrace breakpoints

2011-04-22 Thread Frederic Weisbecker
manipulating them. Reported-by: Oleg Nesterov o...@redhat.com Signed-off-by: Frederic Weisbecker fweis...@gmail.com Cc: Ingo Molnar mi...@elte.hu Cc: Benjamin Herrenschmidt b...@kernel.crashing.org Cc: Peter Zijlstra a.p.zijls...@chello.nl Cc: Will Deacon will.dea...@arm.com Cc: Prasad pra

Re: [PATCH 12/40] x86, compat: convert ia32 layer to use

2010-06-23 Thread Frederic Weisbecker
On Wed, Jun 23, 2010 at 12:14:02PM +0200, Christoph Hellwig wrote: Any reason we need to differenciate between COMPAT_SYSCALL_DEFINE and ARCH_COMPAT_SYSCALL_DEFINE? We don't need this for native system calls, so I can't see the reason to do it for compat system calls. I think we wanted

Re: [PATCH 31/40] trace syscalls: Convert various generic compat syscalls

2010-06-23 Thread Frederic Weisbecker
On Wed, Jun 23, 2010 at 12:19:38PM +0200, Andi Kleen wrote: , Ian Munsie wrote: From: Ian Munsieimun...@au1.ibm.com This patch converts numerous trivial compat syscalls through the generic kernel code to use the COMPAT_SYSCALL_DEFINE family of macros. Why? This just makes the code look

Re: [PATCH 12/40] x86, compat: convert ia32 layer to use

2010-06-23 Thread Frederic Weisbecker
On Wed, Jun 23, 2010 at 12:46:04PM +0200, Christoph Hellwig wrote: On Wed, Jun 23, 2010 at 12:36:21PM +0200, Frederic Weisbecker wrote: I think we wanted that to keep the sys32_ prefixed based naming, to avoid collisions with generic compat handler names. For native syscalls we do

Re: [PATCH 31/40] trace syscalls: Convert various generic compat syscalls

2010-06-23 Thread Frederic Weisbecker
On Wed, Jun 23, 2010 at 12:37:44PM +0200, Andi Kleen wrote: , Frederic Weisbecker wrote: On Wed, Jun 23, 2010 at 12:19:38PM +0200, Andi Kleen wrote: , Ian Munsie wrote: From: Ian Munsieimun...@au1.ibm.com This patch converts numerous trivial compat syscalls through the generic kernel code

Re: [PATCH 10/40] tracing: add tracing support for compat syscalls

2010-06-23 Thread Frederic Weisbecker
On Wed, Jun 23, 2010 at 11:26:26AM -0400, Steven Rostedt wrote: On Wed, 2010-06-23 at 20:02 +1000, Ian Munsie wrote: From: Jason Baron jba...@redhat.com Add core support to event tracing for compat syscalls. The basic idea is that we check if we have a compat task via

Re: [Patch 1/4] Allow arch-specific cleanup before breakpoint unregistration

2010-05-26 Thread Frederic Weisbecker
On Wed, May 26, 2010 at 10:47:42PM +0530, K.Prasad wrote: On Wed, May 26, 2010 at 10:54:41AM +0100, David Howells wrote: K.Prasad pra...@linux.vnet.ibm.com wrote: My understanding is weak function definitions must appear in a different C file than their call sites to work on

Re: [Patch 1/4] Allow arch-specific cleanup before breakpoint unregistration

2010-05-26 Thread Frederic Weisbecker
On Wed, May 26, 2010 at 11:01:24PM +0530, K.Prasad wrote: On Wed, May 26, 2010 at 07:23:15PM +0200, Frederic Weisbecker wrote: On Wed, May 26, 2010 at 10:47:42PM +0530, K.Prasad wrote: On Wed, May 26, 2010 at 10:54:41AM +0100, David Howells wrote: K.Prasad pra...@linux.vnet.ibm.com wrote

Re: ftrace syscalls, PowerPC: Fixes and PowerPC raw syscall tracepoint implementation

2010-05-13 Thread Frederic Weisbecker
On Thu, May 13, 2010 at 12:06:11PM -0400, Steven Rostedt wrote: Frederic, I'm fine with these patches, but since you mainly did the syscall work, I'll let you take them. Sure. The patches that touch the PowerPC code needs an acked-by from Ben or Paul. -- Steve Ok, Thanks.

Re: linux-next: PowerPC WARN_ON_ONCE() after merge of the final tree (tip related)

2010-04-16 Thread Frederic Weisbecker
On Fri, Apr 16, 2010 at 12:38:43PM +0200, Peter Zijlstra wrote: On Thu, 2010-04-15 at 19:15 +0200, Frederic Weisbecker wrote: that looks rather ugly. Why not do a raw: this_cpu_inc(lockdep_stats.redundant_hardirqs_on); which basically open-codes debug_atomic_inc

Re: linux-next: PowerPC WARN_ON_ONCE() after merge of the final tree (tip related)

2010-04-15 Thread Frederic Weisbecker
On Thu, Apr 15, 2010 at 08:49:40AM +0200, Ingo Molnar wrote: * Stephen Rothwell s...@canb.auug.org.au wrote: Hi all, Yesterday's (and today's) linux-next boot (PowerPC) failed like this: [ cut here ] Badness at kernel/lockdep.c:2301 NIP:

Re: linux-next: PowerPC WARN_ON_ONCE() after merge of the final tree (tip related)

2010-04-15 Thread Frederic Weisbecker
On Thu, Apr 15, 2010 at 04:03:58PM +0200, Ingo Molnar wrote: In this case, I guess the following fix should be sufficient? I'm going to test it and provide a sane changelog. diff --git a/kernel/lockdep.c b/kernel/lockdep.c index 78325f8..65d4336 100644 --- a/kernel/lockdep.c +++

Re: linux-next: PowerPC WARN_ON_ONCE() after merge of the final tree (tip related)

2010-04-15 Thread Frederic Weisbecker
On Thu, Apr 15, 2010 at 04:03:58PM +0200, Ingo Molnar wrote: diff --git a/kernel/lockdep.c b/kernel/lockdep.c index 78325f8..65d4336 100644 --- a/kernel/lockdep.c +++ b/kernel/lockdep.c @@ -2298,7 +2298,11 @@ void trace_hardirqs_on_caller(unsigned long ip) return;

Re: [PATCH v2] powerpc/perf_events: Implement perf_arch_fetch_caller_regs

2010-03-18 Thread Frederic Weisbecker
On Thu, Mar 18, 2010 at 04:05:13PM +1100, Paul Mackerras wrote: This implements a powerpc version of perf_arch_fetch_caller_regs. It's implemented in assembly because that way we can be sure there isn't a stack frame for perf_arch_fetch_caller_regs. If it was in C, gcc might or might not

Re: [PATCH] powerpc/perf_events: Implement perf_arch_fetch_caller_regs for powerpc

2010-03-16 Thread Frederic Weisbecker
On Tue, Mar 16, 2010 at 02:22:13PM +1100, Paul Mackerras wrote: On Mon, Mar 15, 2010 at 10:04:54PM +0100, Frederic Weisbecker wrote: On Mon, Mar 15, 2010 at 04:46:15PM +1100, Paul Mackerras wrote: 14.99%perf [kernel.kallsyms] [k] ._raw_spin_lock

Re: [PATCH] powerpc/perf_events: Implement perf_arch_fetch_caller_regs for powerpc

2010-03-15 Thread Frederic Weisbecker
On Mon, Mar 15, 2010 at 04:46:15PM +1100, Paul Mackerras wrote: This implements a powerpc version of perf_arch_fetch_caller_regs. It's implemented in assembly because that way we can be sure there isn't a stack frame for perf_arch_fetch_caller_regs. If it was in C, gcc might or might not

Re: [Patch 1/1] PPC64-HWBKPT: Implement hw-breakpoints for PPC64

2010-02-26 Thread Frederic Weisbecker
On Tue, Feb 23, 2010 at 04:27:15PM +0530, K.Prasad wrote: On Mon, Feb 22, 2010 at 06:47:46PM +0530, K.Prasad wrote: On Sun, Feb 21, 2010 at 02:01:37AM +0100, Frederic Weisbecker wrote: On Mon, Feb 15, 2010 at 11:29:14AM +0530, K.Prasad wrote: [snipped] Also, do you think addr/len/type

Re: [Patch 1/1] PPC64-HWBKPT: Implement hw-breakpoints for PPC64

2010-02-25 Thread Frederic Weisbecker
On Mon, Feb 22, 2010 at 06:47:46PM +0530, K.Prasad wrote: The 'name' field here is actually a legacy inherited from x86 code. It is part of x86's arch-specific hw-breakpoint structure since: - inspired by the kprobe implementation which accepts symbol name as input. - kallsyms_lookup_name()

Re: [Patch 1/1] PPC64-HWBKPT: Implement hw-breakpoints for PPC64

2010-02-20 Thread Frederic Weisbecker
On Mon, Feb 15, 2010 at 11:29:14AM +0530, K.Prasad wrote: +struct arch_hw_breakpoint { + u8 len; /* length of the target symbol */ + int type; + char*name; /* Contains name of the symbol to set bkpt */ + unsigned long address; +}; I

Re: [RFC:PATCH 00/03] powerpc: Expose BookE debug registers through extended ptrace interface

2010-01-30 Thread Frederic Weisbecker
On Sun, Jan 31, 2010 at 08:33:25AM +1100, Benjamin Herrenschmidt wrote: We have one field for addr, one for len and one for the memory access type. I think that those three are enough to express breakpoint ranges. Basically a breakpoint range is a breakpoint that can have a high

Re: [PATCH] macintosh: Explicitly set llseek to no_llseek in ans-lcd

2009-10-21 Thread Frederic Weisbecker
On Wed, Oct 21, 2009 at 11:07:18PM +0200, John Kacur wrote: From 0c2b412cdccf73bdeb19bb866bfe556942eaeca2 Mon Sep 17 00:00:00 2001 From: John Kacur jka...@redhat.com Date: Wed, 21 Oct 2009 23:01:12 +0200 Subject: [PATCH] macintosh: Explicitly set llseek to no_llseek in ans-lcd Now that

Re: [PATCH] macintosh: Explicitly set llseek to no_llseek in ans-lcd

2009-10-21 Thread Frederic Weisbecker
On Wed, Oct 21, 2009 at 11:33:17PM +0200, John Kacur wrote: Should we better pushdown default_llseek to every to every file operations that don't implement llseek? I don't know how many of them don't implement llseek() though. That said we can't continue anymore with this default

Re: [PATCH] macintosh: Explicitly set llseek to no_llseek in ans-lcd

2009-10-21 Thread Frederic Weisbecker
On Wed, Oct 21, 2009 at 11:53:21PM +0200, John Kacur wrote: No problem with that. Setting no_llseek or generic_file_llseek_unlocked, depending on the context is the right thing to do. What I'm wondering about concerns the future code that will have no llsek() implemented in their fops.

Re: [PATCH 0/7][RFC] function graph tracer port to PowerPC

2009-02-12 Thread Frederic Weisbecker
On Thu, Feb 12, 2009 at 11:31:44AM -0500, Steven Rostedt wrote: On Thu, 12 Feb 2009, Frederic Weisbecker wrote: On Wed, Feb 11, 2009 at 08:10:51PM -0500, Steven Rostedt wrote: The following set of patches are RFC and not for inclusion (unless everyone is fine with them

Re: [PATCH 0/7][RFC] function graph tracer port to PowerPC

2009-02-11 Thread Frederic Weisbecker
On Wed, Feb 11, 2009 at 08:10:51PM -0500, Steven Rostedt wrote: The following set of patches are RFC and not for inclusion (unless everyone is fine with them as is). This is the port to PowerPC of the function graph tracer that was written by Frederic Weisbecker for the x86 architecture

Re: [PATCH 0/7][RFC] function graph tracer port to PowerPC

2009-02-11 Thread Frederic Weisbecker
On Wed, Feb 11, 2009 at 09:16:57PM -0500, Steven Rostedt wrote: On Thu, 12 Feb 2009, Frederic Weisbecker wrote: On Wed, Feb 11, 2009 at 08:10:51PM -0500, Steven Rostedt wrote: The following set of patches are RFC and not for inclusion (unless everyone is fine with them