All of lore.kernel.org
 help / color / mirror / Atom feed
From: Carsten Emde <C.Emde@osadl.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: LKML <linux-kernel@vger.kernel.org>, Ingo Molnar <mingo@elte.hu>,
	Steven Rostedt <rostedt@goodmis.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Frederic Weisbecker <fweisbec@gmail.com>
Subject: Re: [PATCH 1/1] fix-task-states-in-sched_switch-event.patch
Date: Mon, 17 May 2010 19:27:49 +0200	[thread overview]
Message-ID: <4BF17C95.3060304@osadl.org> (raw)
In-Reply-To: <1274115243.5605.5255.camel@twins>

On 05/17/2010 06:54 PM, Peter Zijlstra wrote:
> On Mon, 2010-05-17 at 17:21 +0200, Carsten Emde wrote:
>
>>> Since we all love vile macro magic, is the below any better?
>>>
>>> include/linux/task_states.h
>>>
>>> TASK_STATE(RUNNING, "R", "running")
>>> TASK_STATE(INTERRUPTIBLE, "S", "sleeping")
>>> ...
>> Well, yes, this looks very nice and is perfectly readable and
>> maintainable.
>>
>>> enum {
>>> #define TASK_STATE(tstate, tstate_c, tstate_s) __TASK_##tstate,
>>> #include<linux/task_states.h>
>>> #undef TASK_STATE
>>> };
>>>
>>> enum {
>>> #define TASK_STATE(tstate, tstate_c, tstate_s) \
>>> 	TASK_##tstate = 1<<   __TASK_##tstate,
>>> #include<linux/task_states.h>
>>> #undef TASK_STATE
>>> };
>>>
>>> const char *task_state_to_char =
>>> #define TASK_STATE(tstate, tstate_c, tstate_s) tstate_c
>>> #include<linux/task_states.h>
>>> #undef TASK_STATE
>>> ;
>>>
>>> const char *task_state_to_string[] = {
>>> #define TASK_STATE(tstate, tstate_c, tstate_s) tstate_s,
>>> #include<linux/task_states.h>
>>> #undef TASK_STATE
>>> };
>> I find this section less convincing (although certainly
>> indistinguishable from magic).
>>
>> In addition, we need to take care of the various state name prefixes
>> TASK, __TASK and EXIT and name clashes:
>> TASK_RUNNING
>> TASK_INTERRUPTIBLE
>> TASK_UNINTERRUPTIBLE
>> __TASK_STOPPED
>> __TASK_TRACED
>> EXIT_ZOMBIE
>> EXIT_DEAD
>> TASK_DEAD
>> TASK_WAKEKILL
>> TASK_WAKING
>
> We could manually add:
>
> #define EXIT_ZOMBIE TASK_ZOMBIE
> #define EXIT_DEAD TASK_DEAD
>
> But those two __TASK ones are unfortunate indeed.
>
>> And we still need to maintain the defines in include/trace/events/
>> sched.h:
>> { 1, TASK_STATE_1 } , { 2, TASK_STATE_2 },
>> { 4, TASK_STATE_4 }, { 8, TASK_STATE_8 },
>> { 16, TASK_STATE_16 }, { 32, TASK_STATE_32 },
>> { 64, TASK_STATE_64 }, { 128, TASK_STATE_128 },
>> { 256, TASK_STATE_256 }
>> ) : TASK_STATE_0,
>
> #define TASK_STATE(tstate, tstate_c, tstate_s) \
> 	{ __TASK_##tstate, tstate_c },
> #include<linux/task_state.h>
> #undef TASK_STATE
>
> Should get you mostly there I guess, trick would be making the user deal
> with { 0, "R" }
>
>> If we could use a general approach for all states, I would immediately
>> go for your proposal. But since we anyway need to define the states
>> individually, I would vote for the current version of the patch.
>>
>> Or would you prefer to simply apply a minimal fix to correct the
>> erroneous output of the sched_switch event and to leave the rest as an
>> exercise for the future?
>
> Dunno, I guess we can do with your version, just wanted to mention this
> method.
Yes, thanks, your method is great - much better than using intermediate
scripts and similar. However, this approach works best, if you start
with a new design and you are free to arrange everything to build on
it. At least, we should have this approach in mind when making upgrade
changes in the related code - maybe, your method will fit better one
day.

	Carsten.

      reply	other threads:[~2010-05-17 17:29 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-16 22:18 [PATCH 0/1] tracing/sched: Fix task states in sched_switch event Carsten Emde
2010-05-16 22:18 ` [PATCH 1/1] fix-task-states-in-sched_switch-event.patch Carsten Emde
2010-05-17 12:22   ` Peter Zijlstra
2010-05-17 15:21     ` Carsten Emde
2010-05-17 16:54       ` Peter Zijlstra
2010-05-17 17:27         ` Carsten Emde [this message]

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=4BF17C95.3060304@osadl.org \
    --to=c.emde@osadl.org \
    --cc=akpm@linux-foundation.org \
    --cc=fweisbec@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.