Messages in this thread | | | Date | Thu, 18 Oct 2018 12:47:13 +0200 | From | Juri Lelli <> | Subject | Re: INFO: rcu detected stall in do_idle |
| |
Hi,
On 18/10/18 12:23, luca abeni wrote: > Hi Juri, > > On Thu, 18 Oct 2018 10:28:38 +0200 > Juri Lelli <juri.lelli@redhat.com> wrote: > [...] > > struct sched_attr { > > .size = 0, > > .policy = 6, > > .flags = 0, > > .nice = 0, > > .priority = 0, > > .runtime = 0x9917, > > .deadline = 0xffff, > > .period = 0, > > } > > > > So, we seem to be correctly (in theory, see below) accepting the task. > > > > What seems to generate the problem here is that CONFIG_HZ=100 and > > reproducer task has "tiny" runtime (~40us) and deadline (~66us) > > parameters, combination that "bypasses" the enforcing mechanism > > (performed at each tick). > > Ok, so the task can execute for at most 1 tick before being throttled... > Which does not look too bad. > > I missed the original emails, but maybe the issue is that the task > blocks before the tick, and when it wakes up again something goes wrong > with the deadline and runtime assignment? (maybe because the deadline > is in the past?)
No, the problem is that the task won't be throttled at all, because its replenishing instant is always way in the past when tick occurs. :-/
> > Another side problem seems also to be that with such tiny parameters > > we spend lot of time in the while (dl_se->runtime <= 0) loop of > > replenish_dl_ entity() (actually uselessly, as deadline is most > > probably going to still be in the past when eventually runtime > > becomes positive again), as delta_exec is huge w.r.t. runtime and > > runtime has to keep up with tiny increments of dl_runtime. I guess we > > could ameliorate things here by limiting the number of time we > > execute the loop before bailing out. > > Actually, I think the loop will iterate at most 10ms / 39us times, which > is about 256 times, right? If this is too much (I do not know how much > time it is spent executing the loop), then the solution is (as you > suggest) to increase the minimum allowed runtime.
Yeah, it's maybe not a big issue (and fixing it won't change anything regarding the real problem at hand). Just thought I'd mention what I was seeing; and having the loop limit won't harm anyway I guess.
> [...] > > So, I tend to think that we might want to play safe and put some > > higher minimum value for dl_runtime (it's currently at 1ULL << > > DL_SCALE). Guess the problem is to pick a reasonable value, though. > > Maybe link it someway to HZ? > > Yes, a value dependent on HZ looks like a good idea. I would propose > HZ / N, where N is the maximum number of times you want the loop above > to be executed.
Mmm, it's not really about the loop, but about the granularity at which we do enforcement.
> > Then we might add a sysctl (or similar) > > thing with which knowledgeable users can do whatever they think their > > platform/config can support? > > I guess this can be related to the utilization limits we were > discussing some time ago... I would propose a cgroup-based interface to > set all of these limits.
Guess we can go that path as well. But I'd leave it for a later stage.
Thanks,
- Juri
| |