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
Date: Mon, 20 Apr 2020 11:26:40 +0800 [thread overview]
Message-ID: <87368yu9an.fsf@yhuang-dev.intel.com> (raw)
In-Reply-To: <20200417100633.GU20730@hirez.programming.kicks-ass.net> (Peter Zijlstra's message of "Fri, 17 Apr 2020 12:06:33 +0200")
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
prev parent reply other threads:[~2020-04-20 3:26 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-14 8:19 [RFC] autonuma: Support to scan page table asynchronously Huang Ying
2020-04-14 12:06 ` Mel Gorman
2020-04-15 8:14 ` Huang, Ying
2020-04-17 7:05 ` SeongJae Park
2020-04-17 10:04 ` Peter Zijlstra
2020-04-17 10:21 ` SeongJae Park
2020-04-17 12:16 ` Mel Gorman
2020-04-17 12:21 ` Peter Zijlstra
2020-04-17 12:44 ` SeongJae Park
2020-04-17 14:46 ` Mel Gorman
2020-04-18 9:48 ` SeongJae Park
2020-04-20 2:32 ` Huang, Ying
2020-04-15 11:32 ` Peter Zijlstra
2020-04-16 1:24 ` Huang, Ying
2020-04-17 10:06 ` Peter Zijlstra
2020-04-20 3:26 ` Huang, Ying [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87368yu9an.fsf@yhuang-dev.intel.com \
--to=ying.huang@intel.com \
--cc=aubrey.li@intel.com \
--cc=daniel.m.jordan@oracle.com \
--cc=dave.hansen@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=mgorman@techsingularity.net \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=riel@surriel.com \
--cc=tim.c.chen@intel.com \
--cc=tj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).