From: Raghavendra K T <raghavendra.kt@amd.com>
To: Mike Galbraith <efault@gmx.de>, Chen Yu <yu.c.chen@intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Juri Lelli <juri.lelli@redhat.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Tim Chen <tim.c.chen@intel.com>, Yujie Liu <yujie.liu@intel.com>,
K Prateek Nayak <kprateek.nayak@amd.com>,
"Gautham R . Shenoy" <gautham.shenoy@amd.com>,
Chen Yu <yu.chen.surf@gmail.com>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 1/2] sched/fair: Record the average duration of a task
Date: Wed, 3 Jul 2024 19:10:04 +0530 [thread overview]
Message-ID: <8c4f0bf2-0e8e-b94e-070b-47dbd407b70d@amd.com> (raw)
In-Reply-To: <4e28fd17d7a2f7146aae10a76982f0e58b22befb.camel@gmx.de>
On 7/3/2024 5:27 PM, Mike Galbraith wrote:
> On Wed, 2024-07-03 at 14:04 +0530, Raghavendra K T wrote:
>>
>>
>> On 7/1/2024 8:27 PM, Chen Yu wrote:
>>>
>>> A thought occurred to me that one possible method to determine if the waker
>>> and wakee share data could be to leverage the NUMA balance's numa_group data structure.
>>> As numa balance periodically scans the task's VMA space and groups tasks accessing
>>> the same physical page into one numa_group, we can infer that if the waker and wakee
>>> are within the same numa_group, they are likely to share data, and it might be
>>> appropriate to place the wakee on top of the waker.
>>>
>>> CC Raghavendra here in case he has any insights.
>>>
>>
>> Agree with your thought here,
>>
>> So I imagine two possible things to explore here.
>>
>> 1) Use task1, task2 numa_group and check if they belong to same
>> numa_group, also check if there is a possibility of M:N relationship
>> by checking if t1/t2->numa_group->nr_tasks > 1 etc
>>
>> 2) Given a VMA we can use vma_numab_state pids_active[] if task1, task2
>> (threads) possibly interested in same VMA.
>> Latter one looks to be practically difficult because we don't want to
>> sweep across VMAs perhaps..
>
> Oooh dear.. as soon as you mention threads, the question of who's
> wheelhouse is this in springs to mind, ie should the kernel be
> overriding userspace by targeting bits of threaded programs for forced
> serialization?
>
Yes.. There is no ROI on this option (mentioned only for completeness).
also we are not looking beyond process. Rather than "Practically
difficult" I should have rephrased as Practically not an option.
> Bah, think I'll just bugger off and let you guys have a go at making
> this stacking business do less harm than good.
>
> -Mike
next prev parent reply other threads:[~2024-07-03 13:40 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-25 7:21 [PATCH 0/2] sched/fair: Enhance sync wakeup for short duration tasks Chen Yu
2024-06-25 7:22 ` [PATCH 1/2] sched/fair: Record the average duration of a task Chen Yu
2024-06-26 4:21 ` Mike Galbraith
2024-06-30 13:09 ` Chen Yu
2024-07-01 6:57 ` Mike Galbraith
2024-07-01 14:57 ` Chen Yu
2024-07-02 5:08 ` Mike Galbraith
2024-07-03 8:34 ` Raghavendra K T
2024-07-03 11:57 ` Mike Galbraith
2024-07-03 13:23 ` Chen Yu
2024-07-03 13:45 ` Mike Galbraith
2024-07-03 13:40 ` Raghavendra K T [this message]
2024-07-03 13:12 ` Chen Yu
2024-07-03 13:46 ` Raghavendra K T
2024-08-05 4:38 ` Madadi Vineeth Reddy
2024-08-05 7:22 ` Chen Yu
2024-06-25 7:22 ` [PATCH 2/2] sched/fair: Enhance sync wakeup for short duration tasks Chen Yu
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=8c4f0bf2-0e8e-b94e-070b-47dbd407b70d@amd.com \
--to=raghavendra.kt@amd.com \
--cc=efault@gmx.de \
--cc=gautham.shenoy@amd.com \
--cc=juri.lelli@redhat.com \
--cc=kprateek.nayak@amd.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=tim.c.chen@intel.com \
--cc=vincent.guittot@linaro.org \
--cc=yu.c.chen@intel.com \
--cc=yu.chen.surf@gmail.com \
--cc=yujie.liu@intel.com \
/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
all inboxes | Powered by JetHome®