linux-kernel - Re: [Question] Do we need remote charging for cpu and cpuacct subsys?

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:   Fri, 9 Jul 2021 11:17:56 -0400
From:   Daniel Jordan <daniel.m.jordan@...cle.com>
To:     Hao Lee <haolee.swjtu@...il.com>
Cc:     linux-mm@...ck.org, cgroups@...r.kernel.org,
        linux-kernel@...r.kernel.org, tj@...nel.org
Subject: Re: [Question] Do we need remote charging for cpu and cpuacct subsys?

Hi,

[only replying now b/c I was out most of this week]

On Sun, Jul 04, 2021 at 12:18:22AM +0800, Hao Lee wrote:
> On Sat, Jul 3, 2021 at 4:07 AM Daniel Jordan <daniel.m.jordan@...cle.com> wrote:
> > So naturally, I'm curious about your use case and how it may be
> > different from these others. What kworkers would you like to account?
> 
> Thanks. We use a workqueue to perform asynchronous reclaim for cgroups.
> The kworker may consume lots of CPU cycles if the cgroup memory pressure
> is extremely high, so we want to charge the cpu usage to the related
> cgroup for which the kworker works. Otherwise, the reclaim kworker will
> steal cpu time from the system level, which breaks the resource isolation.

Ok, that helps.

> I also have a question here. Are the back-charging and remote charging
> the same thing?

Basically yes.

> > The only one I'm aware of
> > that's like that is net rx, where the work to process packets has to
> > start before their ultimate destination, and therefore cgroup, is known.
> 
> Sorry. Is this a typo?  It seems the word "known" should be "unknown"...

What I'm saying is, the work to process packets starts when the cgroup
is unknown.