Re: [PATCH] sched: let __sched_period() use rq cfs's nr_running
From: Byungchul Park
Date: Thu Jul 09 2015 - 00:57:57 EST
On Wed, Jul 08, 2015 at 09:19:14AM +0900, Byungchul Park wrote:
> On Tue, Jul 07, 2015 at 01:28:18PM -0700, Cong Wang wrote:
> > On Mon, Jul 6, 2015 at 9:40 PM, <byungchul.park@xxxxxxx> wrote:
> > > From: Byungchul Park <byungchul.park@xxxxxxx>
> > >
> > > __sched_period() returns a period which a rq can have. the period has to be
> > > stretched by the number of task *the rq has*, when nr_running > nr_latency.
> > > otherwise, task slice can be very smaller than sysctl_sched_min_granularity
> > > depending on the position of tg hierarchy when CONFIG_FAIR_GROUP_SCHED.
> >
> >
> > Hmm, rq_of(cfs_rq)->cfs should point to the root cfs_rq whose
> > ->nr_running is number of running entities at root level? This
> > doesn't look right.
>
> hello, cong wang,
>
> __sched_period() returns a root level period now. stretching the period with
> a local task group's nr_running is meaningless for getting this period.
> is there something i missed? :)
i am very sorry for my wrong patch, with which i cannot achieve what i intend.
what i intended is to use rq_of(cfs_rq)'s nr_number, not rq_of(cfs_rq)->cfs's,
so that __sched_period() returns a period which a rq can have. i need resend
patch :( but i wonder what do you think about my basic concern?
thank you,
byungchul
>
> thank you,
> byungchul
>
> > --
> > 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/
> --
> 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/
--
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/