From: Heiko Carstens <heiko.carstens@de.ibm.com>
To: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Cc: akpm@linux-foundation.org, Ingo Molnar <mingo@elte.hu>,
linux-kernel@vger.kernel.org,
"Frank Ch. Eigler" <fche@redhat.com>,
Jason Baron <jbaron@redhat.com>, Tom Zanussi <tzanussi@gmail.com>,
fweisbec@gmail.com, laijs@cn.fujitsu.com, rostedt@goodmis.org,
peterz@infradead.org, jiayingz@google.com, roland@redhat.com,
mbligh@google.com,
Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>,
Martin Schwidefsky <schwidefsky@de.ibm.com>
Subject: Re: [RFC patch 14/20] LTTng Kernel Trace Thread Flag s390
Date: Mon, 11 May 2009 10:25:45 +0200 [thread overview]
Message-ID: <20090511102545.3a6ae7cb@osiris.boeblingen.de.ibm.com> (raw)
In-Reply-To: <20090509162350.477343212@polymtl.ca>
On Sat, 09 May 2009 12:22:23 -0400
Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> wrote:
> Add a thread flag to activate system-wide syscall tracing.
>
> Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
> ---
> arch/s390/include/asm/thread_info.h | 2 ++
> arch/s390/kernel/entry.S | 10 ++++++++--
> arch/s390/kernel/entry64.S | 10 ++++++++--
> 3 files changed, 18 insertions(+), 4 deletions(-)
>
> Index: linux-2.6-lttng/arch/s390/include/asm/thread_info.h
> ===================================================================
> --- linux-2.6-lttng.orig/arch/s390/include/asm/thread_info.h 2009-03-15 15:57:04.000000000 -0400
> +++ linux-2.6-lttng/arch/s390/include/asm/thread_info.h 2009-03-15 15:57:17.000000000 -0400
> @@ -90,6 +90,7 @@ static inline struct thread_info *curren
> #define TIF_SYSCALL_AUDIT 5 /* syscall auditing active */
> #define TIF_SINGLE_STEP 6 /* deliver sigtrap on return to user */
> #define TIF_MCCK_PENDING 7 /* machine check handling is pending */
> +#define TIF_KERNEL_TRACE 8 /* kernel trace active */
> #define TIF_USEDFPU 16 /* FPU was used by this task this quantum (SMP) */
> #define TIF_POLLING_NRFLAG 17 /* true if poll_idle() is polling
> TIF_NEED_RESCHED */
> @@ -107,6 +108,7 @@ static inline struct thread_info *curren
> #define _TIF_SYSCALL_AUDIT (1<<TIF_SYSCALL_AUDIT)
> #define _TIF_SINGLE_STEP (1<<TIF_SINGLE_STEP)
> #define _TIF_MCCK_PENDING (1<<TIF_MCCK_PENDING)
> +#define _TIF_KERNEL_TRACE (1<<TIF_KERNEL_TRACE)
> #define _TIF_USEDFPU (1<<TIF_USEDFPU)
> #define _TIF_POLLING_NRFLAG (1<<TIF_POLLING_NRFLAG)
> #define _TIF_31BIT (1<<TIF_31BIT)
> Index: linux-2.6-lttng/arch/s390/kernel/entry.S
> ===================================================================
> --- linux-2.6-lttng.orig/arch/s390/kernel/entry.S 2009-03-15 15:51:10.000000000 -0400
> +++ linux-2.6-lttng/arch/s390/kernel/entry.S 2009-03-15 15:57:17.000000000 -0400
> @@ -265,7 +265,9 @@ sysc_do_restart:
> sth %r7,SP_SVCNR(%r15)
> sll %r7,2 # svc number *4
> l %r8,BASED(.Lsysc_table)
> - tm __TI_flags+3(%r9),(_TIF_SYSCALL_TRACE|_TIF_SYSCALL_AUDIT)
> + l %r8,__TI_flags+3(%r9)
> + n %r8,BASED(.Lc_tif_syscall_trace_or_audit_or_kernel_trace)
> + ltr %r8,%r8
> l %r8,0(%r7,%r8) # get system call addr.
> bnz BASED(sysc_tracesys)
That would be two more instructions (ltr is not needed) and an
additional memory access instead of just one for the fast path just
for debugging purposes.
All this can be avoided if the TIF flags would be rearranged. And
that's exactly what I already did because I needed it for something
else.
Please have a look at linux-next.
next prev parent reply other threads:[~2009-05-11 8:25 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-09 16:22 [RFC patch 00/20] Kernel tracing thread flag Mathieu Desnoyers
2009-05-09 16:22 ` [RFC patch 01/20] LTTng Kernel Trace Thread Flag Alpha Mathieu Desnoyers
2009-05-09 16:22 ` [RFC patch 02/20] LTTng Kernel Trace Thread Flag ARM Mathieu Desnoyers
2009-05-09 16:22 ` [RFC patch 03/20] LTTng Kernel Trace Thread Flag AVR32 Mathieu Desnoyers
2009-05-09 16:22 ` [RFC patch 04/20] LTTng Kernel Trace Thread Flag Blackfin Mathieu Desnoyers
2009-05-09 16:22 ` [RFC patch 05/20] LTTng Kernel Trace Thread Flag Cris Mathieu Desnoyers
2009-05-09 16:22 ` [RFC patch 06/20] LTTng Kernel Trace Thread Flag Frv Mathieu Desnoyers
2009-05-09 16:22 ` [RFC patch 07/20] LTTng Kernel Trace Thread Flag H8300 Mathieu Desnoyers
2009-05-09 16:22 ` [RFC patch 08/20] LTTng Kernel Trace Thread Flag ia64 Mathieu Desnoyers
2009-05-09 16:22 ` [RFC patch 09/20] LTTng Kernel Trace Thread Flag m32r Mathieu Desnoyers
2009-05-09 16:22 ` [RFC patch 10/20] LTTng Kernel Trace Thread Flag m68k Mathieu Desnoyers
2009-05-09 16:22 ` [RFC patch 11/20] LTTng Kernel Trace Thread Flag MIPS Mathieu Desnoyers
2009-05-09 16:22 ` [RFC patch 12/20] LTTng Kernel Trace Thread Flag parisc Mathieu Desnoyers
2009-05-09 16:22 ` [RFC patch 13/20] LTTng Kernel Trace Thread Flag powerpc Mathieu Desnoyers
2009-05-09 16:22 ` [RFC patch 14/20] LTTng Kernel Trace Thread Flag s390 Mathieu Desnoyers
2009-05-11 8:25 ` Heiko Carstens [this message]
2009-05-09 16:22 ` [RFC patch 15/20] LTTng Kernel Trace Thread Flag SH Mathieu Desnoyers
2009-05-09 17:15 ` Paul Mundt
2009-05-09 16:22 ` [RFC patch 16/20] LTTng Kernel Trace Thread Flag sparc Mathieu Desnoyers
2009-05-09 16:22 ` [RFC patch 17/20] LTTng Kernel Trace Thread Flag UML Mathieu Desnoyers
2009-05-09 16:22 ` [RFC patch 18/20] LTTng Linux Kernel Trace Thread Flag x86 Mathieu Desnoyers
2009-05-09 16:22 ` [RFC patch 19/20] LTTng Kernel Trace Thread Flag xtensa Mathieu Desnoyers
2009-05-09 16:22 ` [RFC patch 20/20] LTTng Kernel Trace Thread Flag API Mathieu Desnoyers
2009-05-10 23:04 ` [RFC patch 00/20] Kernel tracing thread flag Roland McGrath
-- strict thread matches above, loose matches on Subject: below --
2009-03-15 20:01 [RFC patch 00/20] LTTng Kernel Trace Thread Flag v2 Mathieu Desnoyers
2009-03-15 20:01 ` [RFC patch 14/20] LTTng Kernel Trace Thread Flag s390 Mathieu Desnoyers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090511102545.3a6ae7cb@osiris.boeblingen.de.ibm.com \
--to=heiko.carstens@de.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=fche@redhat.com \
--cc=fweisbec@gmail.com \
--cc=jbaron@redhat.com \
--cc=jiayingz@google.com \
--cc=laijs@cn.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@polymtl.ca \
--cc=mbligh@google.com \
--cc=mingo@elte.hu \
--cc=peterz@infradead.org \
--cc=roland@redhat.com \
--cc=rostedt@goodmis.org \
--cc=schwidefsky@de.ibm.com \
--cc=tzanussi@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome