On Wed, Dec 20, 2017 at 06:27:17PM +0100, Juri Lelli wrote:
> Thanks Peter for taking the patches. I was actually waiting for the flag
> thing to be resolved to post again. :/
Yeah, I took them because it made sorting that easier, n/p.
On 20/12/17 15:47, Rafael J. Wysocki wrote:
> On Wednesday, December 20, 2017 2:28:26 PM CET Peter Zijlstra wrote:
> > On Wed, Dec 20, 2017 at 12:55:46PM +, Patrick Bellasi wrote:
> > > On 20-Dec 09:31, Peter Zijlstra wrote:
> >
> > > > Didn't juri have patches to make DL do something sane? Bu
On 20-Dec 15:52, Rafael J. Wysocki wrote:
> On Wednesday, December 20, 2017 3:31:00 PM CET Patrick Bellasi wrote:
> > On 20-Dec 14:28, Peter Zijlstra wrote:
> > > On Wed, Dec 20, 2017 at 12:55:46PM +, Patrick Bellasi wrote:
> > > > On 20-Dec 09:31, Peter Zijlstra wrote:
> > >
> > > > > Didn't
On Wednesday, December 20, 2017 3:31:00 PM CET Patrick Bellasi wrote:
> On 20-Dec 14:28, Peter Zijlstra wrote:
> > On Wed, Dec 20, 2017 at 12:55:46PM +, Patrick Bellasi wrote:
> > > On 20-Dec 09:31, Peter Zijlstra wrote:
> >
> > > > Didn't juri have patches to make DL do something sane? But ye
On Wed, Dec 20, 2017 at 03:47:23PM +0100, Rafael J. Wysocki wrote:
> > Well, we still need flags for crap like IO-WAIT IIRC. That's sugov
> > internal state and not something the scheduler actually already knows.
>
> Not only sugov to be precise, but yes.
Oh, right, intel_pstate also consumes tha
On Wednesday, December 20, 2017 2:28:26 PM CET Peter Zijlstra wrote:
> On Wed, Dec 20, 2017 at 12:55:46PM +, Patrick Bellasi wrote:
> > On 20-Dec 09:31, Peter Zijlstra wrote:
>
> > > Didn't juri have patches to make DL do something sane? But yes, I think
> > > those flags are part of the probl
On 20-Dec 14:28, Peter Zijlstra wrote:
> On Wed, Dec 20, 2017 at 12:55:46PM +, Patrick Bellasi wrote:
> > On 20-Dec 09:31, Peter Zijlstra wrote:
>
> > > Didn't juri have patches to make DL do something sane? But yes, I think
> > > those flags are part of the problem.
> >
> > He recently repos
On Wed, Dec 20, 2017 at 12:55:46PM +, Patrick Bellasi wrote:
> On 20-Dec 09:31, Peter Zijlstra wrote:
> > Didn't juri have patches to make DL do something sane? But yes, I think
> > those flags are part of the problem.
>
> He recently reposted them here:
>
> https://lkml.kernel.org/r/20171
On 20-Dec 09:31, Peter Zijlstra wrote:
> On Wed, Dec 20, 2017 at 09:34:46AM +0530, Viresh Kumar wrote:
> > On 19-12-17, 20:25, Peter Zijlstra wrote:
> > > Yeah, not happy about this either; we had code that did the right thing
> > > without this extra tracking I think.
> >
> > Sure, but how do you
On Wed, Dec 20, 2017 at 02:18:59PM +0530, Viresh Kumar wrote:
> On 20-12-17, 09:31, Peter Zijlstra wrote:
> What about this case: A CFS task is running currently and an RT task
> is enqueued.
>
> - Is it always the case that the CFS task is preempted immediately and
> the CPU is given to RT task
On 20-12-17, 09:31, Peter Zijlstra wrote:
> On Wed, Dec 20, 2017 at 09:34:46AM +0530, Viresh Kumar wrote:
> Please use the normal link format:
>
> https://lkml.kernel.org/r/$MSGID
>
> Then I can find them without having to resort to a frigging browser
> thing.
Sure, and that would be much eas
On Wed, Dec 20, 2017 at 09:34:46AM +0530, Viresh Kumar wrote:
> On 19-12-17, 20:25, Peter Zijlstra wrote:
> > Yeah, not happy about this either; we had code that did the right thing
> > without this extra tracking I think.
>
> Sure, but how do you suggest we fix the problems we are facing with
> t
On 19-12-17, 20:25, Peter Zijlstra wrote:
> Yeah, not happy about this either; we had code that did the right thing
> without this extra tracking I think.
Sure, but how do you suggest we fix the problems we are facing with
the current design? Patrick had a completely different proposal for
solving
On Wed, Dec 13, 2017 at 03:23:21PM +0530, Viresh Kumar wrote:
> Currently the schedutil governor overwrites the sg_cpu->flags field on
> every call to the utilization handler. It was pretty good as the initial
> implementation of utilization handlers, there are several drawbacks
> though.
>
> The
On Tuesday, December 19, 2017 4:41:18 AM CET Viresh Kumar wrote:
> On 18-12-17, 19:30, Joel Fernandes wrote:
> > Yes that's clean to me but then as Rafael said, the use of this flag
> > will be too specific for schedutil-only sg_cpu->flags clearing purpose
> > right?
>
> And so would be the extra
On 18-12-17, 19:30, Joel Fernandes wrote:
> Yes that's clean to me but then as Rafael said, the use of this flag
> will be too specific for schedutil-only sg_cpu->flags clearing purpose
> right?
And so would be the extra parameter ?
--
viresh
On Mon, Dec 18, 2017 at 7:26 PM, Viresh Kumar wrote:
> On 19-12-17, 08:52, Viresh Kumar wrote:
>> On 18-12-17, 19:18, Joel Fernandes wrote:
>> > Hi Viresh,
>> >
>> > On Mon, Dec 18, 2017 at 7:12 PM, Viresh Kumar
>> > wrote:
>> > > On 18-12-17, 12:14, Patrick Bellasi wrote:
>> > >> For example, s
On 19-12-17, 08:52, Viresh Kumar wrote:
> On 18-12-17, 19:18, Joel Fernandes wrote:
> > Hi Viresh,
> >
> > On Mon, Dec 18, 2017 at 7:12 PM, Viresh Kumar
> > wrote:
> > > On 18-12-17, 12:14, Patrick Bellasi wrote:
> > >> For example, swithing from:
> > >>
> > >> - void (*func)(struct update_util
On 18-12-17, 19:18, Joel Fernandes wrote:
> Hi Viresh,
>
> On Mon, Dec 18, 2017 at 7:12 PM, Viresh Kumar wrote:
> > On 18-12-17, 12:14, Patrick Bellasi wrote:
> >> For example, swithing from:
> >>
> >> - void (*func)(struct update_util_data *data, u64 time,
> >> - unsigned int flag
Hi Viresh,
On Mon, Dec 18, 2017 at 7:12 PM, Viresh Kumar wrote:
> On 18-12-17, 12:14, Patrick Bellasi wrote:
>> For example, swithing from:
>>
>> - void (*func)(struct update_util_data *data, u64 time,
>> - unsigned int flags))
>> + void (*func)(struct update_util_data *data, u64
On 18-12-17, 12:14, Patrick Bellasi wrote:
> For example, swithing from:
>
> - void (*func)(struct update_util_data *data, u64 time,
> - unsigned int flags))
> + void (*func)(struct update_util_data *data, u64 time,
> + unsigned int flags, bool set))
>
> Where the ad
On Mon, Dec 18, 2017 at 12:59 PM, Viresh Kumar wrote:
> On 18-12-17, 12:35, Rafael J. Wysocki wrote:
>> Well, if SCHED_CPUFRREQ_CLEAR means "this CPU is going to enter the
>> idle loop" really, then it is better to call it
>> SCHED_CPUFRREQ_ENTER_IDLE, for example.
>>
>> SCHED_CPUFRREQ_CLEAR meani
On 18-Dec 17:29, Viresh Kumar wrote:
> On 18-12-17, 12:35, Rafael J. Wysocki wrote:
> > Well, if SCHED_CPUFRREQ_CLEAR means "this CPU is going to enter the
> > idle loop" really, then it is better to call it
> > SCHED_CPUFRREQ_ENTER_IDLE, for example.
> >
> > SCHED_CPUFRREQ_CLEAR meaning basically
On 18-12-17, 12:35, Rafael J. Wysocki wrote:
> Well, if SCHED_CPUFRREQ_CLEAR means "this CPU is going to enter the
> idle loop" really, then it is better to call it
> SCHED_CPUFRREQ_ENTER_IDLE, for example.
>
> SCHED_CPUFRREQ_CLEAR meaning basically "you should clear these flags
> now" doesn't see
On Mon, Dec 18, 2017 at 5:59 AM, Viresh Kumar wrote:
> On 17-12-17, 01:19, Rafael J. Wysocki wrote:
>> We can do that in principle, but why should it return early? Maybe it's
>> a good time to update things, incidentally?
>>
>> I actually don't like the SCHED_CPUFRREQ_CLEAR flag *concept* as it i
On 17-12-17, 01:19, Rafael J. Wysocki wrote:
> We can do that in principle, but why should it return early? Maybe it's
> a good time to update things, incidentally?
>
> I actually don't like the SCHED_CPUFRREQ_CLEAR flag *concept* as it is very
> much specific to schedutil and blatantly ignores e
On Saturday, December 16, 2017 5:47:07 PM CET Viresh Kumar wrote:
> On 16 December 2017 at 22:10, Rafael J. Wysocki wrote:
> > On Wed, Dec 13, 2017 at 10:53 AM, Viresh Kumar
> > wrote:
>
> >> +#define SCHED_CPUFREQ_CLEAR(1U << 31)
> >
> > I'm not thrilled by this, because schedutil is not t
On 16 December 2017 at 22:10, Rafael J. Wysocki wrote:
> On Wed, Dec 13, 2017 at 10:53 AM, Viresh Kumar
> wrote:
>> +#define SCHED_CPUFREQ_CLEAR(1U << 31)
>
> I'm not thrilled by this, because schedutil is not the only user of
> the flags and it's totally unclear what the other user(s) shou
On Wed, Dec 13, 2017 at 10:53 AM, Viresh Kumar wrote:
> Currently the schedutil governor overwrites the sg_cpu->flags field on
> every call to the utilization handler. It was pretty good as the initial
> implementation of utilization handlers, there are several drawbacks
> though.
>
> The biggest
On 13-12-17, 12:26, Juri Lelli wrote:
> This flag doesn't do much, does it? I mean RT/DL/IOWAIT are used to bump
> up frequency, while you are adding CFS for the sake of simmetry, right?
> And with my patches DL will hopefully soon be in the same situation.
> If my understanding is correct, maybe a
Hi Viresh,
On 13/12/17 15:23, Viresh Kumar wrote:
> Currently the schedutil governor overwrites the sg_cpu->flags field on
> every call to the utilization handler. It was pretty good as the initial
> implementation of utilization handlers, there are several drawbacks
> though.
>
> The biggest dra
31 matches
Mail list logo
