linux-kernel - Re: [RFC] autonuma: Support to scan page table asynchronously

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]

Message-ID: <87368yu9an.fsf@yhuang-dev.intel.com>
Date:   Mon, 20 Apr 2020 11:26:40 +0800
From:   "Huang\, Ying" <ying.huang@...el.com>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     Mel Gorman <mgorman@...hsingularity.net>, <linux-mm@...ck.org>,
        <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...hat.com>,
        Mel Gorman <mgorman@...e.de>, Rik van Riel <riel@...riel.com>,
        Daniel Jordan <daniel.m.jordan@...cle.com>,
        Tejun Heo <tj@...nel.org>, Dave Hansen <dave.hansen@...el.com>,
        Tim Chen <tim.c.chen@...el.com>,
        Aubrey Li <aubrey.li@...el.com>
Subject: Re: [RFC] autonuma: Support to scan page table asynchronously

Peter Zijlstra <peterz@...radead.org> writes:

> On Thu, Apr 16, 2020 at 09:24:35AM +0800, Huang, Ying wrote:
>> Peter Zijlstra <peterz@...radead.org> writes:
>> 
>> > On Tue, Apr 14, 2020 at 01:06:46PM +0100, Mel Gorman wrote:
>> >> While it's just an opinion, my preference would be to focus on reducing
>> >> the cost and amount of scanning done -- particularly for threads.
>> >
>> > This; I really don't believe in those back-charging things, esp. since
>> > not having cgroups or having multiple applications in a single cgroup is
>> > a valid setup.
>> 
>> Technically, it appears possible to back-charge the CPU time to the
>> process/thread directly (not the cgroup).
>
> I've yet to see a sane proposal there. What we're not going to do is
> make regular task accounting more expensive than it already is.

Yes.  There's overhead to back-charge.  To reduce the overhead, instead
of back-charge immediately, we can

- Add one field to task_struct, say backcharge_time, to track the
  delayed back-charged CPU time.

- When the work item completes its work, add the CPU time it spends to
  task_struct->backcharge_time atomically

- When the task account CPU regularly, e.g. in scheduler_tick(),
  task_struct->backcharge is considered too.

Although this cannot eliminate the overhead, it can reduce it.  Do you
think this is acceptable or not?

Best Regards,
Huang, Ying