linux-kernel - Re: [External] Re: [PATCH v2] sched/cpuacct: Fix charge cpuacct.usage

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] [day] [month] [year] [list]

Date:   Wed, 3 Mar 2021 11:39:56 +0800
From:   Muchun Song <songmuchun@...edance.com>
To:     Michal Koutný <mkoutny@...e.com>
Cc:     Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Juri Lelli <juri.lelli@...hat.com>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        dietmar.eggemann@....com, Steven Rostedt <rostedt@...dmis.org>,
        Benjamin Segall <bsegall@...gle.com>,
        Mel Gorman <mgorman@...e.de>, Ingo Molnar <mingo@...nel.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [External] Re: [PATCH v2] sched/cpuacct: Fix charge
 cpuacct.usage_sys incorrently.

On Wed, Mar 3, 2021 at 1:43 AM Michal Koutný <mkoutny@...e.com> wrote:
>
> Hello.
>
> (Sorry for necroposting, found this upstream reference only now.)
>
> On Mon, Apr 20, 2020 at 03:04:53PM +0800, Muchun Song <songmuchun@...edance.com> wrote:
> >  /* Time spent by the tasks of the CPU accounting group executing in ... */
> > @@ -339,7 +340,7 @@ void cpuacct_charge(struct task_struct *tsk, u64 cputime)
> >  {
> >       struct cpuacct *ca;
> >       int index = CPUACCT_STAT_SYSTEM;
> > -     struct pt_regs *regs = task_pt_regs(tsk);
> > +     struct pt_regs *regs = get_irq_regs() ? : task_pt_regs(tsk);
> I've read the discussion in [1] but I don't think this approach is
> correct either (and I don't know what is better :-/).

Yes. It didn't solve the problem completely. I am trying to
count the sys time as much as possible, but the sys time here
still can be lower than the real situation. I didn't think of a better
solution.

>
> I only have a qualitative proof:
>
> host:~ # uname -r
> 5.10.16-1-default
>
> host:~ # systemd-run -p CPUAccounting=yes sh -c 'time sh -c "i=0 ; while [ \"\$i\" -lt 10000 ] ; do i=\$((\$i+1)) ; cat /proc/slabinfo >/dev/null ; done" ; sleep inf'
> Running as unit: run-r101b9f53efcb4d2a9bfb65feb6f120ca.service
>
> host:~ # cat /sys/fs/cgroup/cpuacct/system.slice/run-r101b9f53efcb4d2a9bfb65feb6f120ca.service/cpuacct.usage{,_user,_sys}
> 16138535165
> 14332580468
> 1805954697
>
> (See that sys/user ~ 0.1)
>
> host:~ # journalctl -u run-r101b9f53efcb4d2a9bfb65feb6f120ca.service
> -- Logs begin at Tue 2021-03-02 18:06:41 CET, end at Tue 2021-03-02 18:27:45 CET. --
> Mar 02 18:27:29 host systemd[1]: Started /usr/bin/sh -c time sh -c "i=0 ; while [ \"\$i\" -lt 10000 ] ; do i=\$((\$i+1)) ; cat /proc/slabinfo >/dev/null ; done" ; sleep inf.
> Mar 02 18:27:45 host sh[19117]: real        0m15.543s
> Mar 02 18:27:45 host sh[19117]: user        0m10.752s
> Mar 02 18:27:45 host sh[19117]: sys        0m5.379s
>
> (See that sys/user ~ 0.5)
>
> host:~ # cat /sys/fs/cgroup/cpuacct/system.slice/run-r101b9f53efcb4d2a9bfb65feb6f120ca.service/cpuacct.stat
> user 415
> system 1209
>
> (See that sys/user ~ 3.0 :-o)
>
> The expectation is that significant amount of the loop is spent in
> kernel (dumping slabinfo). I can't tell which of the ratios fits the
> reality best but the cpuacct.usage_sys still seems too low.
>
>
> Michal
>
> [1] https://lore.kernel.org/lkml/20200416141833.50663-1-songmuchun@bytedance.com/