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: <CAK1hUK_eZ9UubbiTaXwvwN0Q9eyVohrkVZ+Lz+1tCnQqHXjNig@mail.gmail.com>
Date:   Sat, 27 Aug 2016 23:13:43 +0800
From:   Mac Lin <mkl0301@...il.com>
To:     Vegard Nossum <vegard.nossum@...il.com>
Cc:     John Stultz <john.stultz@...aro.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: Random abnormal high CPU sys usage related to timer

Hi Vegard,
Thanks for the prompt response.
The commit is introduced since 4.6, but the issue can be reproduced at
3.10 (earliest I have ever test). And testing on buildroot+4.7 with
the commit reverted, the issue still happen.

In fact, I did a test that ran a script that keep increase a counter
for 10 seconds on the same CPU. If I ran 2 of it, the number is half
of running 1. But if I ran it while the issue happened, the counter
reported is around the same value as the 1 process case. So I doubt
that it might be an issue of reported number.

Is there other way to ensure the CPU is "really" doing something?

x=0
trap 'echo x=$x;exit 1' SIGHUP SIGINT SIGTERM
while : ; do
        x=$(($x+1));
#       echo $x;
done


On Sat, Aug 27, 2016 at 5:12 AM, Vegard Nossum <vegard.nossum@...il.com> wrote:
> On 26 August 2016 at 19:10, Mac Lin <mkl0301@...il.com> wrote:
>> We were having issue with our userspace application which
>> __sometimes__ result in high CPU sys usage at each execution. The high
>> sys CPU usage persist until the application is killed.
> [...]
>> Googling found one issue that seems related, but no further action.
>
> Was it this one? https://lkml.org/lkml/2016/8/23/360
>
> If so you may try to revert commit ff9a9b4c4334 ("sched, time: Switch
> VIRT_CPU_ACCOUNTING_GEN to jiffy granularity") to see if it helps.
>
>
> Vegard

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ