Re: [PATCH] sched: Update scheduler stat documentation.

From: Ingo Molnar
Date: Tue Jan 17 2012 - 04:51:09 EST



* Rakib Mullick <rakib.mullick@xxxxxxxxx> wrote:

> On Mon, Jan 16, 2012 at 2:36 PM, Ingo Molnar <mingo@xxxxxxx> wrote:
> >
> >
> > Yes - but we should also change it to export a value of zero.
> > The field is a legacy 'array expirations' field, and as such it
> > should be zero.
> >
>
> Ok, thanks for suggestions. Please, look at the following patch, it's
> been roughly created to address your suggestion. If it looks okay,
> then I can send formal patch (perhaps two separate patches?). In this
> way, I think we can also remove rq->sched_switch field (not done in
> this patch)?
>
> diff --git a/Documentation/scheduler/sched-stats.txt
> b/Documentation/scheduler/sched-stats.txt
> index 1cd5d51..cc2d107 100644
> --- a/Documentation/scheduler/sched-stats.txt
> +++ b/Documentation/scheduler/sched-stats.txt
> @@ -38,7 +38,8 @@ First field is a sched_yield() statistic:
> 1) # of times sched_yield() was called
>
> Next three are schedule() statistics:
> - 2) # of times we switched to the expired queue and reused it
> + 2) This field is a legacy array expiration field used in O(1) scheduler.
> + But still kept for ABI integrity.

I'd formulate it like this:

> + 2) This field is a legacy array expiration count field
> + used in the O(1) scheduler. We kept it for ABI
> + compatibility, but it is always set to zero.


> + int rq_sched_switch = 0;
> #ifdef CONFIG_SMP
> struct sched_domain *sd;
> int dcount = 0;
> @@ -34,7 +35,7 @@ static int show_schedstat(struct seq_file *seq, void *v)
> seq_printf(seq,
> "cpu%d %u %u %u %u %u %u %llu %llu %lu",
> cpu, rq->yld_count,
> - rq->sched_switch, rq->sched_count, rq->sched_goidle,
> + rq_sched_switch, rq->sched_count, rq->sched_goidle,

printf can print a 0 value just fine as part of the format
string ... :-)

But yeah, this logic is what i had in mind.

Thanks,

Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/