mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Kayra Cizmeci <kayracizmeci@gmail.com>
To: jackzxcui1989@163.com
Cc: bsegall@google.com, dietmar.eggemann@arm.com,
	juri.lelli@redhat.com, kayracizmeci@gmail.com,
	kprateek.nayak@amd.com, linux-kernel@vger.kernel.org,
	mgorman@suse.de, mingo@redhat.com, peterz@infradead.org,
	rostedt@goodmis.org, vincent.guittot@linaro.org,
	vschneid@redhat.com
Subject: Re: [RFC PATCH RESEND 05/10] sched/fair: Introduce select_task_rq_fair_thin() to select rq when LB_PROMOTE
Date: Tue, 15 Sep 2026 21:19:59 +0300	[thread overview]
Message-ID: <20260915181959.19936-1-kayracizmeci@gmail.com> (raw)
In-Reply-To: <20260910145658.2003786-1-jackzxcui1989@163.com>

Hello Xin,

> > > Testing has shown that in our system with 18 CPUs running at 2.1GHz, where
> > > the first three sd_llc domains each contains 4 CPUs and the last sd_llc
> > > contains 2 CPUs, under same fillback scenario, select_task_rq_fair_thin()
> > > executes 25% faster than the original select_task_rq_fair(). It saves 22ms
> > > over a 10-second period, with this optimization accounting for 0.174% of
> > > total system time. Additionally, we measured the execution time of
> > > update_idle_cpu_scan, which took 0.5ms over the same 10-second period. If
> > > we use select_task_rq_fair_thin() instead, this time can be eliminated,
> > > accounting for 0.04% of total system time. Therefore, the overall
> > > optimization contributes to a reduction of 0.214% of total system time.
> > 
> > Okay. Can you specify which tests you ran or what you used? If you can?

> I used a relatively crude and straightforward method, which involves
> subtracting the time at the beginning and end of the select_task_rq_fair()
> function and then accumulating the per-CPU time. I retrieve this accumulated
> value a kernel module (ko). The detailed script is as follows:

> Below is the test script for comparing the effect of select_task_rq_fair()
> with and without the patch:

> #!/bin/bash

> insmod testselecttask. patch=0 on=1
> sleep 10
> insmod testselecttask.ko patch=0 on=0
> cat testselecttask_patch_0.txt

> sleep 1
> insmod testselecttask.ko patch=1 on=1sleep 10
> insmod testselecttask.ko patch=1 on=0
> cat testselecttask_patch_1.txt

> Test results:

> root@hobot:/map/zhaoxin# ./smalltest.sh
> ins: ERROR: could not insert module testselecttask.ko: Invalid parameters
> insmod: ERROR: could not insert module testselecttask.ko: Invalid parameters
> zhaoxin: enable[0] count[179226] timens[09325] avg[460]
> insmod: ERROR: could not insert module testselecttask.ko: Invalid parameters
> insmod: ERROR: could not insert module testselecttask.ko: Invalid parameters
> zhaoxin: enable[1 count[180836] timens[59444800] avg[328]

> From the test results, combined with the following information:

> Currently, the machine's overall sys time is about 7%, multiplied by 18
> cores, which results approximately 126% for a multi-core CPU. The test
> duration is 10 seconds, and within that time, 22 ms is saved, which
> translates to 2.2 ms per second, equating to 0.0022 for multi, or 0.22%.
> The time taken by this function is generally linked to the total sys time,
> and the optimized portion accounts for about 0.174% of the total sys time.

> Below are the test results for the execution time ofupdate_idle_cpu_scan`:

> root@hobot:/map/zhaoxin# ./smalltest.sh
> insmod: ERROR: could not insert module testselecttask.ko: Invalid parameters
> insmod: ERROR: could not insert moduleselecttask.ko: Invalid parameters
> zhaoxin: enable[0] count[179226] timens[82509325] avg[460]
> insmod: ERROR: could not insert module testselecttask.ko: Invalid parameters
> mod: ERROR: could not insert module testselecttask.ko: Invalid parameters
> zhaoxin: enable[1] count[180836] timens[59444800] avg[328]

> From the test results, combined with following information:

> Currently, the machine's overall sys time is about 7%, multiplied by 18
> cores, which results in approximately 126% for a multi-core CPU. The test
> duration is 10 seconds, and within that time, 22 is saved, which translates
> to 2.2 ms per second, equating to 0.0022 for multi-core, or 0.22%. The time
> taken by this function is generally linked to the total sys time, and the
> optimized accounts for about 0.174% of the total sys time.

Are you trying to measure the time that it takes to take to reach end of the function?

I'm really not understanding anything from here. There are multiple errors. 
Can you give more details?

It would be better if you could use ftrace or something like that instead a custom test.




  reply	other threads:[~2026-09-15 18:20 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-10  4:29 [RFC PATCH RESEND 00/10] sched/fair: A series of load balance patches to improve real-time performance of CFS tasks Xin Zhao
2026-09-10  4:29 ` [RFC PATCH RESEND 01/10] sched/fair: Do not set_rd_overloaded() if rd->online != env->cpus Xin Zhao
2026-09-10  8:30   ` K Prateek Nayak
2026-09-10 13:45     ` Vincent Guittot
2026-09-11  1:06     ` Xin Zhao
2026-09-11  6:21       ` K Prateek Nayak
2026-09-12  1:46         ` Xin Zhao
2026-09-12  1:53         ` Xin Zhao
2026-09-10  4:29 ` [RFC PATCH RESEND 02/10] scbed/fair: Remove duplicate check for busiest_cpu in active_load_balance_cpu_stop() Xin Zhao
2026-09-10 11:41   ` Kayra Cizmeci
2026-09-11  0:22     ` Xin Zhao
2026-09-11  9:20       ` Kayra Cizmeci
2026-09-10  4:29 ` [RFC PATCH RESEND 03/10] sched/fair: Clear active_balance at the end of active_load_balance_cpu_stop() Xin Zhao
2026-09-10  8:09   ` K Prateek Nayak
2026-09-10 14:15     ` Xin Zhao
2026-09-10  4:29 ` [RFC PATCH RESEND 04/10] sched/fair: Add LB_PROMOTE feature to enhance real-time performance of fair tasks Xin Zhao
2026-09-11 12:32   ` Vincent Guittot
2026-09-12  4:28     ` Xin Zhao
2026-09-10  4:29 ` [RFC PATCH RESEND 05/10] sched/fair: Introduce select_task_rq_fair_thin() to select rq when LB_PROMOTE Xin Zhao
2026-09-10  8:19   ` Vincent Guittot
2026-09-10 14:39     ` Xin Zhao
2026-09-10 15:31       ` Vincent Guittot
2026-09-10 15:56         ` Xin Zhao
2026-09-11 12:27           ` Vincent Guittot
2026-09-12  4:08             ` Xin Zhao
2026-09-15 11:56               ` Vincent Guittot
2026-09-15 21:43                 ` Kayra Cizmeci
2026-09-10 12:00   ` Kayra Cizmeci
2026-09-10 14:56     ` Xin Zhao
2026-09-15 18:19       ` Kayra Cizmeci [this message]
2026-09-10  4:29 ` [RFC PATCH RESEND 06/10] sched/fair: Modify active_load_balance_cpu_stop() to accommodate more scenarios Xin Zhao
2026-09-10  4:29 ` [RFC PATCH RESEND 07/10] sched/fair: Trigger active balance if a CFS task is preempted when LB_PROMOTE Xin Zhao
2026-09-10  4:29 ` [RFC PATCH RESEND 08/10] sched/fair: Do not check avg_idle to prematurely exit newly idle " Xin Zhao
2026-09-10  4:29 ` [RFC PATCH RESEND 09/10] sched/fair: Not goto more_balance if newly idle and has pending task when LBF_NEED_BREAK Xin Zhao
2026-09-10  4:29 ` [RFC PATCH RESEND 10/10] sched/fair: Strive to find a task to migrate if newly idle when LB_PROMOTE Xin Zhao

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=20260915181959.19936-1-kayracizmeci@gmail.com \
    --to=kayracizmeci@gmail.com \
    --cc=bsegall@google.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=jackzxcui1989@163.com \
    --cc=juri.lelli@redhat.com \
    --cc=kprateek.nayak@amd.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=vincent.guittot@linaro.org \
    --cc=vschneid@redhat.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®