Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
IronPort-SDR: 98Rb07V6QK9PPrQ0WqEam7u24KdCdJDl4CVkVMWEMOiLOPnmhsVxbLhsgCyRDQsDW8uiHMLzG4
 S/cKV03Pe/MQ==
IronPort-SDR: 3ivqihb11g1hPSROSw4eMzCqTmuhzzMlOVw2DRnhT5NpR2CQeh2GG5FmuRe6jyDnydFbaMACPt
 loMEBUQ7JLnA==
From:   "Huang\, Ying" <ying.huang@intel.com>
To:     Peter Zijlstra <peterz@infradead.org>
Cc:     Mel Gorman <mgorman@techsingularity.net>, <linux-mm@kvack.org>,
        <linux-kernel@vger.kernel.org>, Ingo Molnar <mingo@redhat.com>,
        Mel Gorman <mgorman@suse.de>, Rik van Riel <riel@surriel.com>,
        Daniel Jordan <daniel.m.jordan@oracle.com>,
        Tejun Heo <tj@kernel.org>, Dave Hansen <dave.hansen@intel.com>,
        Tim Chen <tim.c.chen@intel.com>,
        Aubrey Li <aubrey.li@intel.com>
Subject: Re: [RFC] autonuma: Support to scan page table asynchronously
References: <20200414081951.297676-1-ying.huang@intel.com>
        <20200414120646.GN3818@techsingularity.net>
        <20200415113226.GE20730@hirez.programming.kicks-ass.net>
        <87o8rsxlws.fsf@yhuang-dev.intel.com>
        <20200417100633.GU20730@hirez.programming.kicks-ass.net>
Date:   Mon, 20 Apr 2020 11:26:40 +0800
In-Reply-To: <20200417100633.GU20730@hirez.programming.kicks-ass.net> (Peter
        Zijlstra's message of "Fri, 17 Apr 2020 12:06:33 +0200")
Message-ID: <87368yu9an.fsf@yhuang-dev.intel.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=ascii
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Peter Zijlstra <peterz@infradead.org> writes:

> On Thu, Apr 16, 2020 at 09:24:35AM +0800, Huang, Ying wrote:
>> Peter Zijlstra <peterz@infradead.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