[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f7a0d098ac635c9596d739515efd4f1bc383c73e.camel@linux.intel.com>
Date: Fri, 10 Jun 2022 14:19:57 -0700
From: Tim Chen <tim.c.chen@...ux.intel.com>
To: Yicong Yang <yangyicong@...wei.com>,
Yicong Yang <yangyicong@...ilicon.com>, peterz@...radead.org,
mingo@...hat.com, juri.lelli@...hat.com,
vincent.guittot@...aro.org, gautham.shenoy@....com,
linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Cc: dietmar.eggemann@....com, rostedt@...dmis.org, bsegall@...gle.com,
bristot@...hat.com, prime.zeng@...wei.com,
jonathan.cameron@...wei.com, ego@...ux.vnet.ibm.com,
srikar@...ux.vnet.ibm.com, linuxarm@...wei.com, 21cnbao@...il.com,
guodong.xu@...aro.org, hesham.almatary@...wei.com,
john.garry@...wei.com, shenyang39@...wei.com,
Chen Yu <yu.c.chen@...el.com>
Subject: Re: [PATCH v4 2/2] sched/fair: Scan cluster before scanning LLC in
wake-up path
On Fri, 2022-06-10 at 14:39 +0800, Yicong Yang wrote:
>
>
> I've tested this patch with MySQL as well (like in v2). This won't hurt
> the MySQL case with SIS_PROP but observed some improvement with SIS_UTIL
> posted in [1]. We leverage the nr to suppress redundant scanning in the
> current approach and seems SIS_UTIL is more efficient in this case.
>
> 5.19-rc1 patched patched+SIS_UTIL[1]
> TPS-16threads 6215.11 6172.74 (-0.68%) 6217.33 (0.04%)
> QPS-16threads 124302.21 123454.68 (-0.68%) 124346.52 (0.04%)
> avg-lat-16threads 2.57 2.59 (-0.65%) 2.57 (0.00%)
> TPS-24threads 8726.40 8690.87 (-0.41%) 8833.08 (1.22%)
> QPS-24threads 174527.88 173817.42 (-0.41%) 176661.54 (1.21%)
> avg-lat-24threads 2.75 2.76 (-0.36%) 2.71 (1.33%)
> TPS-32threads 9555.42 9514.86 (-0.42%) 10010.87 (4.77%)
> QPS-32threads 191108.37 190297.28 (-0.42%) 200217.35 (4.55%)
> avg-lat-32threads 3.35 3.36 (-0.30%) 3.20 (4.58%)
> TPS-64threads 10290.10 10324.75 (0.34%) 10819.77 (5.15%)
> QPS-64threads 205802.05 206494.95 (0.34%) 216395.40 (4.90%)
> avg-lat-64threads 6.22 6.20 (0.38%) 5.92 (4.88%)
>
Thanks for the numbers. SIS_UTIL will keep off migrations off the cluster
that doesn't really improve overall utilization. We have higher chance that
L2 cache is warm. So it makes sense that we see a bit
better performance there.
Tim
Powered by blists - more mailing lists