2007-07-10 00:51:58 +08:00
|
|
|
|
|
|
|
#ifdef CONFIG_SCHEDSTATS
|
2008-10-06 17:23:43 +08:00
|
|
|
|
2007-07-10 00:51:58 +08:00
|
|
|
/*
|
|
|
|
* Expects runqueue lock to be held for atomicity of update
|
|
|
|
*/
|
|
|
|
static inline void
|
|
|
|
rq_sched_info_arrive(struct rq *rq, unsigned long long delta)
|
|
|
|
{
|
|
|
|
if (rq) {
|
|
|
|
rq->rq_sched_info.run_delay += delta;
|
2007-10-15 23:00:12 +08:00
|
|
|
rq->rq_sched_info.pcount++;
|
2007-07-10 00:51:58 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Expects runqueue lock to be held for atomicity of update
|
|
|
|
*/
|
|
|
|
static inline void
|
|
|
|
rq_sched_info_depart(struct rq *rq, unsigned long long delta)
|
|
|
|
{
|
|
|
|
if (rq)
|
2008-12-17 15:41:22 +08:00
|
|
|
rq->rq_cpu_time += delta;
|
2007-07-10 00:51:58 +08:00
|
|
|
}
|
sched: fix accounting in task delay accounting & migration
On Thu, Jun 19, 2008 at 12:27:14PM +0200, Peter Zijlstra wrote:
> On Thu, 2008-06-05 at 10:50 +0530, Ankita Garg wrote:
>
> > Thanks Peter for the explanation...
> >
> > I agree with the above and that is the reason why I did not see weird
> > values with cpu_time. But, run_delay still would suffer skews as the end
> > points for delta could be taken on different cpus due to migration (more
> > so on RT kernel due to the push-pull operations). With the below patch,
> > I could not reproduce the issue I had seen earlier. After every dequeue,
> > we take the delta and start wait measurements from zero when moved to a
> > different rq.
>
> OK, so task delay delay accounting is broken because it doesn't take
> migration into account.
>
> What you've done is make it symmetric wrt enqueue, and account it like
>
> cpu0 cpu1
>
> enqueue
> <wait-d1>
> dequeue
> enqueue
> <wait-d2>
> run
>
> Where you add both d1 and d2 to the run_delay,.. right?
>
Thanks for reviewing the patch. The above is exactly what I have done.
> This seems like a good fix, however it looks like the patch will break
> compilation in !CONFIG_SCHEDSTATS && !CONFIG_TASK_DELAY_ACCT, of it
> failing to provide a stub for sched_info_dequeue() in that case.
Fixed. Pl. find the new patch below.
Signed-off-by: Ankita Garg <ankita@in.ibm.com>
Acked-by: Peter Zijlstra <peterz@infradead.org>
Cc: Gregory Haskins <ghaskins@novell.com>
Cc: rostedt@goodmis.org
Cc: suresh.b.siddha@intel.com
Cc: aneesh.kumar@linux.vnet.ibm.com
Cc: dhaval@linux.vnet.ibm.com
Cc: vatsa@linux.vnet.ibm.com
Cc: David Bahi <DBahi@novell.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-01 17:00:06 +08:00
|
|
|
|
|
|
|
static inline void
|
|
|
|
rq_sched_info_dequeued(struct rq *rq, unsigned long long delta)
|
|
|
|
{
|
|
|
|
if (rq)
|
|
|
|
rq->rq_sched_info.run_delay += delta;
|
|
|
|
}
|
2016-06-18 01:43:24 +08:00
|
|
|
#define schedstat_enabled() static_branch_unlikely(&sched_schedstats)
|
|
|
|
#define schedstat_inc(var) do { if (schedstat_enabled()) { var++; } } while (0)
|
|
|
|
#define schedstat_add(var, amt) do { if (schedstat_enabled()) { var += (amt); } } while (0)
|
|
|
|
#define schedstat_set(var, val) do { if (schedstat_enabled()) { var = (val); } } while (0)
|
2016-06-18 01:43:25 +08:00
|
|
|
#define schedstat_val(var) (var)
|
|
|
|
#define schedstat_val_or_zero(var) ((schedstat_enabled()) ? (var) : 0)
|
2016-06-04 06:58:40 +08:00
|
|
|
|
2007-07-10 00:51:58 +08:00
|
|
|
#else /* !CONFIG_SCHEDSTATS */
|
|
|
|
static inline void
|
|
|
|
rq_sched_info_arrive(struct rq *rq, unsigned long long delta)
|
|
|
|
{}
|
|
|
|
static inline void
|
sched: fix accounting in task delay accounting & migration
On Thu, Jun 19, 2008 at 12:27:14PM +0200, Peter Zijlstra wrote:
> On Thu, 2008-06-05 at 10:50 +0530, Ankita Garg wrote:
>
> > Thanks Peter for the explanation...
> >
> > I agree with the above and that is the reason why I did not see weird
> > values with cpu_time. But, run_delay still would suffer skews as the end
> > points for delta could be taken on different cpus due to migration (more
> > so on RT kernel due to the push-pull operations). With the below patch,
> > I could not reproduce the issue I had seen earlier. After every dequeue,
> > we take the delta and start wait measurements from zero when moved to a
> > different rq.
>
> OK, so task delay delay accounting is broken because it doesn't take
> migration into account.
>
> What you've done is make it symmetric wrt enqueue, and account it like
>
> cpu0 cpu1
>
> enqueue
> <wait-d1>
> dequeue
> enqueue
> <wait-d2>
> run
>
> Where you add both d1 and d2 to the run_delay,.. right?
>
Thanks for reviewing the patch. The above is exactly what I have done.
> This seems like a good fix, however it looks like the patch will break
> compilation in !CONFIG_SCHEDSTATS && !CONFIG_TASK_DELAY_ACCT, of it
> failing to provide a stub for sched_info_dequeue() in that case.
Fixed. Pl. find the new patch below.
Signed-off-by: Ankita Garg <ankita@in.ibm.com>
Acked-by: Peter Zijlstra <peterz@infradead.org>
Cc: Gregory Haskins <ghaskins@novell.com>
Cc: rostedt@goodmis.org
Cc: suresh.b.siddha@intel.com
Cc: aneesh.kumar@linux.vnet.ibm.com
Cc: dhaval@linux.vnet.ibm.com
Cc: vatsa@linux.vnet.ibm.com
Cc: David Bahi <DBahi@novell.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-01 17:00:06 +08:00
|
|
|
rq_sched_info_dequeued(struct rq *rq, unsigned long long delta)
|
|
|
|
{}
|
|
|
|
static inline void
|
2007-07-10 00:51:58 +08:00
|
|
|
rq_sched_info_depart(struct rq *rq, unsigned long long delta)
|
|
|
|
{}
|
2016-06-18 01:43:24 +08:00
|
|
|
#define schedstat_enabled() 0
|
|
|
|
#define schedstat_inc(var) do { } while (0)
|
|
|
|
#define schedstat_add(var, amt) do { } while (0)
|
|
|
|
#define schedstat_set(var, val) do { } while (0)
|
|
|
|
#define schedstat_val(var) 0
|
2016-06-18 01:43:25 +08:00
|
|
|
#define schedstat_val_or_zero(var) 0
|
2016-06-18 01:43:24 +08:00
|
|
|
#endif /* CONFIG_SCHEDSTATS */
|
2007-07-10 00:51:58 +08:00
|
|
|
|
2015-06-26 02:23:37 +08:00
|
|
|
#ifdef CONFIG_SCHED_INFO
|
sched: fix accounting in task delay accounting & migration
On Thu, Jun 19, 2008 at 12:27:14PM +0200, Peter Zijlstra wrote:
> On Thu, 2008-06-05 at 10:50 +0530, Ankita Garg wrote:
>
> > Thanks Peter for the explanation...
> >
> > I agree with the above and that is the reason why I did not see weird
> > values with cpu_time. But, run_delay still would suffer skews as the end
> > points for delta could be taken on different cpus due to migration (more
> > so on RT kernel due to the push-pull operations). With the below patch,
> > I could not reproduce the issue I had seen earlier. After every dequeue,
> > we take the delta and start wait measurements from zero when moved to a
> > different rq.
>
> OK, so task delay delay accounting is broken because it doesn't take
> migration into account.
>
> What you've done is make it symmetric wrt enqueue, and account it like
>
> cpu0 cpu1
>
> enqueue
> <wait-d1>
> dequeue
> enqueue
> <wait-d2>
> run
>
> Where you add both d1 and d2 to the run_delay,.. right?
>
Thanks for reviewing the patch. The above is exactly what I have done.
> This seems like a good fix, however it looks like the patch will break
> compilation in !CONFIG_SCHEDSTATS && !CONFIG_TASK_DELAY_ACCT, of it
> failing to provide a stub for sched_info_dequeue() in that case.
Fixed. Pl. find the new patch below.
Signed-off-by: Ankita Garg <ankita@in.ibm.com>
Acked-by: Peter Zijlstra <peterz@infradead.org>
Cc: Gregory Haskins <ghaskins@novell.com>
Cc: rostedt@goodmis.org
Cc: suresh.b.siddha@intel.com
Cc: aneesh.kumar@linux.vnet.ibm.com
Cc: dhaval@linux.vnet.ibm.com
Cc: vatsa@linux.vnet.ibm.com
Cc: David Bahi <DBahi@novell.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-01 17:00:06 +08:00
|
|
|
static inline void sched_info_reset_dequeued(struct task_struct *t)
|
|
|
|
{
|
|
|
|
t->sched_info.last_queued = 0;
|
|
|
|
}
|
|
|
|
|
2007-07-10 00:51:58 +08:00
|
|
|
/*
|
2010-10-24 18:28:47 +08:00
|
|
|
* We are interested in knowing how long it was from the *first* time a
|
sched: fix accounting in task delay accounting & migration
On Thu, Jun 19, 2008 at 12:27:14PM +0200, Peter Zijlstra wrote:
> On Thu, 2008-06-05 at 10:50 +0530, Ankita Garg wrote:
>
> > Thanks Peter for the explanation...
> >
> > I agree with the above and that is the reason why I did not see weird
> > values with cpu_time. But, run_delay still would suffer skews as the end
> > points for delta could be taken on different cpus due to migration (more
> > so on RT kernel due to the push-pull operations). With the below patch,
> > I could not reproduce the issue I had seen earlier. After every dequeue,
> > we take the delta and start wait measurements from zero when moved to a
> > different rq.
>
> OK, so task delay delay accounting is broken because it doesn't take
> migration into account.
>
> What you've done is make it symmetric wrt enqueue, and account it like
>
> cpu0 cpu1
>
> enqueue
> <wait-d1>
> dequeue
> enqueue
> <wait-d2>
> run
>
> Where you add both d1 and d2 to the run_delay,.. right?
>
Thanks for reviewing the patch. The above is exactly what I have done.
> This seems like a good fix, however it looks like the patch will break
> compilation in !CONFIG_SCHEDSTATS && !CONFIG_TASK_DELAY_ACCT, of it
> failing to provide a stub for sched_info_dequeue() in that case.
Fixed. Pl. find the new patch below.
Signed-off-by: Ankita Garg <ankita@in.ibm.com>
Acked-by: Peter Zijlstra <peterz@infradead.org>
Cc: Gregory Haskins <ghaskins@novell.com>
Cc: rostedt@goodmis.org
Cc: suresh.b.siddha@intel.com
Cc: aneesh.kumar@linux.vnet.ibm.com
Cc: dhaval@linux.vnet.ibm.com
Cc: vatsa@linux.vnet.ibm.com
Cc: David Bahi <DBahi@novell.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-01 17:00:06 +08:00
|
|
|
* task was queued to the time that it finally hit a cpu, we call this routine
|
|
|
|
* from dequeue_task() to account for possible rq->clock skew across cpus. The
|
|
|
|
* delta taken on each cpu would annul the skew.
|
2007-07-10 00:51:58 +08:00
|
|
|
*/
|
2013-09-22 22:20:54 +08:00
|
|
|
static inline void sched_info_dequeued(struct rq *rq, struct task_struct *t)
|
2007-07-10 00:51:58 +08:00
|
|
|
{
|
2013-09-22 22:20:54 +08:00
|
|
|
unsigned long long now = rq_clock(rq), delta = 0;
|
sched: fix accounting in task delay accounting & migration
On Thu, Jun 19, 2008 at 12:27:14PM +0200, Peter Zijlstra wrote:
> On Thu, 2008-06-05 at 10:50 +0530, Ankita Garg wrote:
>
> > Thanks Peter for the explanation...
> >
> > I agree with the above and that is the reason why I did not see weird
> > values with cpu_time. But, run_delay still would suffer skews as the end
> > points for delta could be taken on different cpus due to migration (more
> > so on RT kernel due to the push-pull operations). With the below patch,
> > I could not reproduce the issue I had seen earlier. After every dequeue,
> > we take the delta and start wait measurements from zero when moved to a
> > different rq.
>
> OK, so task delay delay accounting is broken because it doesn't take
> migration into account.
>
> What you've done is make it symmetric wrt enqueue, and account it like
>
> cpu0 cpu1
>
> enqueue
> <wait-d1>
> dequeue
> enqueue
> <wait-d2>
> run
>
> Where you add both d1 and d2 to the run_delay,.. right?
>
Thanks for reviewing the patch. The above is exactly what I have done.
> This seems like a good fix, however it looks like the patch will break
> compilation in !CONFIG_SCHEDSTATS && !CONFIG_TASK_DELAY_ACCT, of it
> failing to provide a stub for sched_info_dequeue() in that case.
Fixed. Pl. find the new patch below.
Signed-off-by: Ankita Garg <ankita@in.ibm.com>
Acked-by: Peter Zijlstra <peterz@infradead.org>
Cc: Gregory Haskins <ghaskins@novell.com>
Cc: rostedt@goodmis.org
Cc: suresh.b.siddha@intel.com
Cc: aneesh.kumar@linux.vnet.ibm.com
Cc: dhaval@linux.vnet.ibm.com
Cc: vatsa@linux.vnet.ibm.com
Cc: David Bahi <DBahi@novell.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-01 17:00:06 +08:00
|
|
|
|
|
|
|
if (unlikely(sched_info_on()))
|
|
|
|
if (t->sched_info.last_queued)
|
|
|
|
delta = now - t->sched_info.last_queued;
|
|
|
|
sched_info_reset_dequeued(t);
|
|
|
|
t->sched_info.run_delay += delta;
|
|
|
|
|
2013-09-22 22:20:54 +08:00
|
|
|
rq_sched_info_dequeued(rq, delta);
|
2007-07-10 00:51:58 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Called when a task finally hits the cpu. We can now calculate how
|
|
|
|
* long it was waiting to run. We also note when it began so that we
|
|
|
|
* can keep stats on how long its timeslice is.
|
|
|
|
*/
|
2013-09-22 22:20:54 +08:00
|
|
|
static void sched_info_arrive(struct rq *rq, struct task_struct *t)
|
2007-07-10 00:51:58 +08:00
|
|
|
{
|
2013-09-22 22:20:54 +08:00
|
|
|
unsigned long long now = rq_clock(rq), delta = 0;
|
2007-07-10 00:51:58 +08:00
|
|
|
|
|
|
|
if (t->sched_info.last_queued)
|
|
|
|
delta = now - t->sched_info.last_queued;
|
sched: fix accounting in task delay accounting & migration
On Thu, Jun 19, 2008 at 12:27:14PM +0200, Peter Zijlstra wrote:
> On Thu, 2008-06-05 at 10:50 +0530, Ankita Garg wrote:
>
> > Thanks Peter for the explanation...
> >
> > I agree with the above and that is the reason why I did not see weird
> > values with cpu_time. But, run_delay still would suffer skews as the end
> > points for delta could be taken on different cpus due to migration (more
> > so on RT kernel due to the push-pull operations). With the below patch,
> > I could not reproduce the issue I had seen earlier. After every dequeue,
> > we take the delta and start wait measurements from zero when moved to a
> > different rq.
>
> OK, so task delay delay accounting is broken because it doesn't take
> migration into account.
>
> What you've done is make it symmetric wrt enqueue, and account it like
>
> cpu0 cpu1
>
> enqueue
> <wait-d1>
> dequeue
> enqueue
> <wait-d2>
> run
>
> Where you add both d1 and d2 to the run_delay,.. right?
>
Thanks for reviewing the patch. The above is exactly what I have done.
> This seems like a good fix, however it looks like the patch will break
> compilation in !CONFIG_SCHEDSTATS && !CONFIG_TASK_DELAY_ACCT, of it
> failing to provide a stub for sched_info_dequeue() in that case.
Fixed. Pl. find the new patch below.
Signed-off-by: Ankita Garg <ankita@in.ibm.com>
Acked-by: Peter Zijlstra <peterz@infradead.org>
Cc: Gregory Haskins <ghaskins@novell.com>
Cc: rostedt@goodmis.org
Cc: suresh.b.siddha@intel.com
Cc: aneesh.kumar@linux.vnet.ibm.com
Cc: dhaval@linux.vnet.ibm.com
Cc: vatsa@linux.vnet.ibm.com
Cc: David Bahi <DBahi@novell.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-01 17:00:06 +08:00
|
|
|
sched_info_reset_dequeued(t);
|
2007-07-10 00:51:58 +08:00
|
|
|
t->sched_info.run_delay += delta;
|
|
|
|
t->sched_info.last_arrival = now;
|
2007-10-15 23:00:12 +08:00
|
|
|
t->sched_info.pcount++;
|
2007-07-10 00:51:58 +08:00
|
|
|
|
2013-09-22 22:20:54 +08:00
|
|
|
rq_sched_info_arrive(rq, delta);
|
2007-07-10 00:51:58 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This function is only called from enqueue_task(), but also only updates
|
|
|
|
* the timestamp if it is already not set. It's assumed that
|
|
|
|
* sched_info_dequeued() will clear that stamp when appropriate.
|
|
|
|
*/
|
2013-09-22 22:20:54 +08:00
|
|
|
static inline void sched_info_queued(struct rq *rq, struct task_struct *t)
|
2007-07-10 00:51:58 +08:00
|
|
|
{
|
|
|
|
if (unlikely(sched_info_on()))
|
|
|
|
if (!t->sched_info.last_queued)
|
2013-09-22 22:20:54 +08:00
|
|
|
t->sched_info.last_queued = rq_clock(rq);
|
2007-07-10 00:51:58 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2013-09-16 16:30:36 +08:00
|
|
|
* Called when a process ceases being the active-running process involuntarily
|
|
|
|
* due, typically, to expiring its time slice (this may also be called when
|
|
|
|
* switching to the idle task). Now we can calculate how long we ran.
|
2008-06-16 17:41:01 +08:00
|
|
|
* Also, if the process is still in the TASK_RUNNING state, call
|
|
|
|
* sched_info_queued() to mark that it has now again started waiting on
|
|
|
|
* the runqueue.
|
2007-07-10 00:51:58 +08:00
|
|
|
*/
|
2013-09-22 22:20:54 +08:00
|
|
|
static inline void sched_info_depart(struct rq *rq, struct task_struct *t)
|
2007-07-10 00:51:58 +08:00
|
|
|
{
|
2013-09-22 22:20:54 +08:00
|
|
|
unsigned long long delta = rq_clock(rq) -
|
2007-11-10 05:39:37 +08:00
|
|
|
t->sched_info.last_arrival;
|
2007-07-10 00:51:58 +08:00
|
|
|
|
2013-09-22 22:20:54 +08:00
|
|
|
rq_sched_info_depart(rq, delta);
|
2008-06-16 17:41:01 +08:00
|
|
|
|
|
|
|
if (t->state == TASK_RUNNING)
|
2013-09-22 22:20:54 +08:00
|
|
|
sched_info_queued(rq, t);
|
2007-07-10 00:51:58 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Called when tasks are switched involuntarily due, typically, to expiring
|
|
|
|
* their time slice. (This may also be called when switching to or from
|
|
|
|
* the idle task.) We are only called when prev != next.
|
|
|
|
*/
|
|
|
|
static inline void
|
2013-09-22 22:20:54 +08:00
|
|
|
__sched_info_switch(struct rq *rq,
|
|
|
|
struct task_struct *prev, struct task_struct *next)
|
2007-07-10 00:51:58 +08:00
|
|
|
{
|
|
|
|
/*
|
|
|
|
* prev now departs the cpu. It's not interesting to record
|
|
|
|
* stats about how efficient we were at scheduling the idle
|
|
|
|
* process, however.
|
|
|
|
*/
|
|
|
|
if (prev != rq->idle)
|
2013-09-22 22:20:54 +08:00
|
|
|
sched_info_depart(rq, prev);
|
2007-07-10 00:51:58 +08:00
|
|
|
|
|
|
|
if (next != rq->idle)
|
2013-09-22 22:20:54 +08:00
|
|
|
sched_info_arrive(rq, next);
|
2007-07-10 00:51:58 +08:00
|
|
|
}
|
|
|
|
static inline void
|
2013-09-22 22:20:54 +08:00
|
|
|
sched_info_switch(struct rq *rq,
|
|
|
|
struct task_struct *prev, struct task_struct *next)
|
2007-07-10 00:51:58 +08:00
|
|
|
{
|
|
|
|
if (unlikely(sched_info_on()))
|
2013-09-22 22:20:54 +08:00
|
|
|
__sched_info_switch(rq, prev, next);
|
2007-07-10 00:51:58 +08:00
|
|
|
}
|
|
|
|
#else
|
2013-09-22 22:20:54 +08:00
|
|
|
#define sched_info_queued(rq, t) do { } while (0)
|
sched: fix accounting in task delay accounting & migration
On Thu, Jun 19, 2008 at 12:27:14PM +0200, Peter Zijlstra wrote:
> On Thu, 2008-06-05 at 10:50 +0530, Ankita Garg wrote:
>
> > Thanks Peter for the explanation...
> >
> > I agree with the above and that is the reason why I did not see weird
> > values with cpu_time. But, run_delay still would suffer skews as the end
> > points for delta could be taken on different cpus due to migration (more
> > so on RT kernel due to the push-pull operations). With the below patch,
> > I could not reproduce the issue I had seen earlier. After every dequeue,
> > we take the delta and start wait measurements from zero when moved to a
> > different rq.
>
> OK, so task delay delay accounting is broken because it doesn't take
> migration into account.
>
> What you've done is make it symmetric wrt enqueue, and account it like
>
> cpu0 cpu1
>
> enqueue
> <wait-d1>
> dequeue
> enqueue
> <wait-d2>
> run
>
> Where you add both d1 and d2 to the run_delay,.. right?
>
Thanks for reviewing the patch. The above is exactly what I have done.
> This seems like a good fix, however it looks like the patch will break
> compilation in !CONFIG_SCHEDSTATS && !CONFIG_TASK_DELAY_ACCT, of it
> failing to provide a stub for sched_info_dequeue() in that case.
Fixed. Pl. find the new patch below.
Signed-off-by: Ankita Garg <ankita@in.ibm.com>
Acked-by: Peter Zijlstra <peterz@infradead.org>
Cc: Gregory Haskins <ghaskins@novell.com>
Cc: rostedt@goodmis.org
Cc: suresh.b.siddha@intel.com
Cc: aneesh.kumar@linux.vnet.ibm.com
Cc: dhaval@linux.vnet.ibm.com
Cc: vatsa@linux.vnet.ibm.com
Cc: David Bahi <DBahi@novell.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
2008-07-01 17:00:06 +08:00
|
|
|
#define sched_info_reset_dequeued(t) do { } while (0)
|
2013-09-22 22:20:54 +08:00
|
|
|
#define sched_info_dequeued(rq, t) do { } while (0)
|
|
|
|
#define sched_info_depart(rq, t) do { } while (0)
|
|
|
|
#define sched_info_arrive(rq, next) do { } while (0)
|
|
|
|
#define sched_info_switch(rq, t, next) do { } while (0)
|
2015-06-26 02:23:37 +08:00
|
|
|
#endif /* CONFIG_SCHED_INFO */
|