Le Fri, Dec 13, 2024 at 07:27:03AM +, LEROY Christophe a écrit :
>
>
> Le 11/12/2024 à 16:40, Frederic Weisbecker a écrit :
> > Use the proper API instead of open coding it.
> >
> > However it looks like kthreads here could be replaced by the use of a
&g
Use the proper API instead of open coding it.
However it looks like kthreads here could be replaced by the use of a
per-cpu workqueue instead.
Signed-off-by: Frederic Weisbecker
---
drivers/soc/fsl/qbman/qman_test_stash.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git
Le Thu, Nov 14, 2024 at 08:38:59AM +0100, Christophe Leroy a écrit :
> Hi,
>
> Le 04/09/2024 à 04:26, Hongbo Li a écrit :
> > Replace kthread_create/kthread_bind/wake_up_process() with
> > kthread_run_on_cpu() to simplify the code.
> >
> > Signed-off-by: Hongbo Li
>
> A similar change is propos
Use the proper API instead of open coding it.
However it looks like kthreads here could be replaced by the use of a
per-cpu workqueue instead.
Signed-off-by: Frederic Weisbecker
---
drivers/soc/fsl/qbman/qman_test_stash.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git
el Ellerman
> Cc: Nathan Lynch
> Cc: linuxppc-dev@lists.ozlabs.org
> Signed-off-by: Anna-Maria Behnsen
> Acked-by: Michael Ellerman (powerpc)
Reviewed-by: Frederic Weisbecker
Use the proper API instead of open coding it.
However it looks like kthreads here could be replaced by the use of a
per-cpu workqueue instead.
Signed-off-by: Frederic Weisbecker
---
drivers/soc/fsl/qbman/qman_test_stash.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git
Use the proper API instead of open coding it.
However it looks like kthreads here could be replaced by the use of a
per-cpu workqueue instead.
Signed-off-by: Frederic Weisbecker
---
drivers/soc/fsl/qbman/qman_test_stash.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git
Use the proper API instead of open coding it.
However it looks like kthreads here could be replaced by the use of a
per-cpu workqueue instead.
Signed-off-by: Frederic Weisbecker
---
drivers/soc/fsl/qbman/qman_test_stash.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git
Use the proper API instead of open coding it.
However it looks like kthreads here could be replaced by the use of a
per-cpu workqueue instead.
Signed-off-by: Frederic Weisbecker
---
drivers/soc/fsl/qbman/qman_test_stash.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git
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 sm
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 add this ch
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
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
on to PowerPC.
>
> Signed-off-by: Alexander Gordeev
Reviewed-by: Frederic Weisbecker
t. Remove it.
>
> Signed-off-by: Alexander Gordeev
Reviewed-by: 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 IP
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:
&
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(&ct->state);
> > + /* will return true only for cpus in kernel space */
> > + return state &
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 cont
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)
> return
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;
> > }
> >
NIDLE() from arm64/risc-v perf code
> - 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!
-by: Tony Lindgren
Reviewed-by: 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
> >
>
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 enable
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
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 enable
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
w with the cpu_pm_*() informations that makes sense:
Reviewed-by: Frederic Weisbecker
u-v7.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
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.
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
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
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
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
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 ab
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
> CONFIG_NO_H
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(&p->wake_entry, &rq->wake_list)) {
> if (!set_nr_if_polling(rq->idle))
> -
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, Frederic Weisbecker wrot
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,
>
> Co
WARN_ON_ONCE(in_nmi());
> > + if (llist_add(&work->llnode, &per_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.
_get_expires(&ts->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
On Thu, Feb 23, 2017 at 08:34:15AM +1100, Michael Ellerman wrote:
> Frederic Weisbecker writes:
>
> > This type conversion is a leftover that got ignored during the kcpustat
> > conversion to nanosecs, resulting in build breakage with config having
> > CONFIG_NO_HZ_
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
>
Cc: Paul Mackerras
Cc: Oliver O'Halloran
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Frederic Weisbecker
---
arch/powerpc/kernel/time.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/time.c b/arch/powerpc/kernel/time.c
index 14e4855..bc84a
gt; kernel/time/posix-cpu-timers.c|4 +-
> 14 files changed, 73 insertions(+), 133 deletions(-)
>
Excellent patchset!
Thanks a lot Stanislaw!
Acked-by: Frederic Weisbecker
Hi Ben,
2015-02-16 5:06 GMT+01:00 Benjamin Herrenschmidt :
> 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 on "IRQ work
2013/10/25 Peter Zijlstra :
> 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
2013/10/23 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(&
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 ba
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
> wrote:
>
> > On Wed, 25 Sep 2013, Andrew Morton wrote:
> > > On Wed, 25 Sep 2013 11:06:43 +1000 Stephen Rothwell
> > > wrote:
> > > > Hi Andrew,
> > > >
> > > > After mergi
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 pro
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 co
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 cod
2013/2/1 Li Zhong :
> 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 patch corresponds
e 17), as it seems there
> is no asm code using it. TIF_NOHZ is added to _TIF_SYCALL_T_OR_A, so it is
> better for it to be in the same 16 bits with others in the group, so in the
> asm code, andi. with this group could work.
>
> Signed-off-by: Li Zhong
Looks good. Thanks.
Acked-by: Fr
2013/2/8 Stephen Rothwell :
> Hi Frederic,
>
> On Fri, 8 Feb 2013 14:07:49 +1100 Stephen Rothwell
> wrote:
>>
>> This patch has the side effect of changing the default configurations:
>> (This is PowerPC pseries_defconfig before/after this patch)
>>
>> @@ -119,8 +120,8 @@
>> #
>> # CPU/Task tim
2013/2/7 Li Zhong :
> 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
2013/2/1 Li Zhong :
> 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 17), as it seems ther
2012/9/25 Michael Neuling :
> Michael Neuling wrote:
>
>> Frederic Weisbecker wrote:
>>
>> > On Thu, Aug 16, 2012 at 02:23:54PM +1000, Michael Neuling wrote:
>> > > Hi,
>> > >
>> > > I've been trying to get hardware breakpoi
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
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:
> >
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 abili
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
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
Acked-by: Will Deacon
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Prasad
Cc: Paul Mundt
So that hw_breakpoints and perf can be not built on
specific embedded systems.
Signed-off-by: Frederic Weisbecker
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Jason Wessel
Cc: H. Peter Anvin
Cc: Thomas Gleixner
---
arch/x86/Kconfig|3 +--
arch/x86/include/asm/debugreg.h
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
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Will Deacon
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
Acked-by: Will Deacon
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Prasad
Cc: Paul Mundt
---
arch/arm/include/asm
-by: Frederic Weisbecker
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Will Deacon
Cc: Prasad
Cc: Paul Mundt
---
arch/Kconfig |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/arch/Kconfig b/arch/Kconfig
index f78c2be..ce4be89 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
to support
this new modularity.
Signed-off-by: Frederic Weisbecker
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Will Deacon
Cc: Prasad
Cc: Paul Mundt
---
arch/sh/Kconfig |1 +
arch/x86/Kconfig |1 +
init/Kconfig | 10 ++
3 files changed, 12 insertions(+), 0 deletions(-)
di
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
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* you
Commit-ID: 925f83c085e1bb08435556c5b4844a60de002e31
Gitweb: http://git.kernel.org/tip/925f83c085e1bb08435556c5b4844a60de002e31
Author: Frederic Weisbecker
AuthorDate: Fri, 6 May 2011 01:53:18 +0200
Committer: Ingo Molnar
CommitDate: Fri, 6 May 2011 11:24:46 +0200
hw_breakpoints
'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
Signed-off-by: Frederic Weisbecker
Cc: Prasad
Cc: v2.6.33..
---
arch/powerpc/kernel/ptrace.c | 15 +++
1 files c
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
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Will Deacon
Cc: Prasad
Cc: Paul Mundt
---
arch/arm
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
Cc: Ingo Molnar
Cc: Peter Zijlstra
Cc: Will Deacon
Cc: Prasad
Cc: Paul Mundt
---
arch/arm/include/asm
manipulating them.
Reported-by: Oleg Nesterov
Signed-off-by: Frederic Weisbecker
Cc: Ingo Molnar
Cc: Benjamin Herrenschmidt
Cc: Peter Zijlstra
Cc: Will Deacon
Cc: Prasad
Cc: Paul Mundt
Cc: v2.6.33..
---
arch/powerpc/kernel/ptrace.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff
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
> >
> > Add core support to event tracing for compat syscalls. The basic idea is
> > that we
> > check if we have a compat task via 'is_compat_task()'. If
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 Munsie
>>>>
>>>> This patch converts numerous t
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
On Wed, Jun 23, 2010 at 12:19:38PM +0200, Andi Kleen wrote:
> , Ian Munsie wrote:
>> From: Ian Munsie
>>
>> 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 uglier and th
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
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:
>
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 wrote:
> >
> > > > My understanding is weak function definitions must appear in a
> > > > different C
> > > > file than their call sites to work on some toolcha
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
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);
> >
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)
> >
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/loc
On Thu, Apr 15, 2010 at 08:49:40AM +0200, Ingo Molnar wrote:
>
> * Stephen Rothwell wrote:
>
> > Hi all,
> >
> > Yesterday's (and today's) linux-next boot (PowerPC) failed like this:
> >
> > [ cut here ]
> > Badness at kernel/lockdep.c:2301
> > NIP: c00a35c8 LR:
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 c
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]
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 c
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]
> >
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_na
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;
> +};
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
On Mon, Jan 25, 2010 at 07:32:00AM +1100, Benjamin Herrenschmidt wrote:
> On Mon, 2010-01-25 at 00:48 +0530, K.Prasad wrote:
> >
> > Some of the benefits of using these generic interfaces include:
> > - Interoperability with other users of debug register (such as
> > parallel
> > kernel requests
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 the
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 defau
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
> Date: Wed, 21 Oct 2009 23:01:12 +0200
> Subject: [PATCH] macintosh: Explicitly set llseek to no_llseek in ans-lcd
>
> Now that we've removed th
1 - 100 of 103 matches
Mail list logo
