linux-kernel - Re: Problem with commit 31e77c93e432 "sched/fair: Update blocked load when newly idle"

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <b39b265d-6a44-6133-6a51-33b8077d2f64@gmail.com>
Date:   Mon, 9 Apr 2018 19:33:32 +0200
From:   Heiner Kallweit <hkallweit1@...il.com>
To:     Vincent Guittot <vincent.guittot@...aro.org>
Cc:     Dietmar Eggemann <dietmar.eggemann@....com>,
        "Peter Zijlstra (Intel)" <peterz@...radead.org>,
        Ingo Molnar <mingo@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "Rafael J. Wysocki" <rafael.j.wysocki@...el.com>
Subject: Re: Problem with commit 31e77c93e432 "sched/fair: Update blocked load
 when newly idle"

Am 06.04.2018 um 18:03 schrieb Vincent Guittot:
> Hi Heiner,
> 
> On 30 March 2018 at 10:37, Heiner Kallweit <hkallweit1@...il.com> wrote:
>> Am 30.03.2018 um 08:50 schrieb Vincent Guittot:
>>> On 29 March 2018 at 19:40, Heiner Kallweit <hkallweit1@...il.com> wrote:
>>>> Am 29.03.2018 um 09:41 schrieb Vincent Guittot:
>>>
>>>>>
>>>>> I'm finally not so sure that i have the right set up to reproduce the
>>>>> problem as I haven't been able to reproduce it since.
>>>>>
>>>>> Heiner,
>>>>>
>>>>> How fast the problem happens on your board ?
>>>>> Are you doing anything specific on the console that trigger the problem ?
>>>>>
>>>> Hi Vincent,
>>>>
>>>> the lag when working on the console is constantly there, the "rcu_preempt
>>>> detected stalls" happens after several hours (so far always within 24h)
>>>> w/o any triggering event I would be aware of. It occured also when the
>>>> system was idle at that point in time.
>>>
>>> Ok, so I don't have the problem on my hikey as the console never lag
>>> on my setup.
>>>
>>> Can you send me the config of  your kernel ? I'd like to check if you
>>> have enable something that could trigger such problem
>>>
>> Sure, he we go. I also add a system log.
> 
> Thanks for the config. I have used it for my setup but I can't
> reproduce your regression. My platforms stay stable so I probably
> missing something. Are you facing similar problem with other platforms
> or only this celeron based platform ?
> 
> I have reviewed the code but don't see any obvious place in the patch
> that can generate the problem. Nevertheless, would you mind to try the
> patch below ? It's a blind test to try to narrow the problem.
> 
> Thanks
> 
Hi Vincent,

I tried again with today's linux-next and it's much better. The lag isn't
completely gone but it's much less annoying. Every ~30 secs the console
hangs for about half a second, that's much less frequent than before.

I saw some patches from Rafael have been merged in the last days.
Maybe they improved the situation.

Regards, Heiner

> ---
>  kernel/sched/fair.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 0951d1c..e9835f2 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -9794,9 +9794,9 @@ static int idle_balance(struct rq *this_rq,
> struct rq_flags *rf)
>   sd = rcu_dereference_check_sched_domain(this_rq->sd);
>   if (sd)
>   update_next_balance(sd, &next_balance);
> - rcu_read_unlock();
> 
>   nohz_newidle_balance(this_rq);
> + rcu_read_unlock();
> 
>   goto out;
>   }
>