From: Thomas Gleixner <tglx@linutronix.de>
To: Fenghua Yu <fenghua.yu@intel.com>
Cc: Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Peter Zijlstra <peterz@infradead.org>,
Tony Luck <tony.luck@intel.com>,
Randy Dunlap <rdunlap@infradead.org>,
Xiaoyao Li <xiaoyao.li@intel.com>,
Ravi V Shankar <ravi.v.shankar@intel.com>,
linux-kernel <linux-kernel@vger.kernel.org>, x86 <x86@kernel.org>
Subject: Re: [PATCH v5 2/3] x86/bus_lock: Handle #DB for bus lock
Date: Mon, 12 Apr 2021 09:15:08 +0200 [thread overview]
Message-ID: <8735vw2cub.ffs@nanos.tec.linutronix.de> (raw)
In-Reply-To: <YGe/IwJSNHnuhU2d@otcwcpicx3.sc.intel.com>
On Sat, Apr 03 2021 at 01:04, Fenghua Yu wrote:
> On Sat, Mar 20, 2021 at 01:42:52PM +0100, Thomas Gleixner wrote:
>> On Fri, Mar 19 2021 at 22:19, Fenghua Yu wrote:
>> And even with throttling the injection rate further down to 25k per
>> second the impact on the workload is still significant in the 10% range.
>
> Thank you for your insight!
>
> So I can change the ratelimit to system wide and call usleep_range()
> to sleep:
> while (!__ratelimit(&global_bld_ratelimit))
> usleep_range(1000000 / bld_ratelimit,
> 1000000 / bld_ratelimit);
>
> The max bld_ratelimit is 1000,000/s because the max sleeping time is 1
> usec.
Maximum sleep time is 1usec?
> The min bld_ratelimit is 1/s.
Again. This does not make sense at all. 1Mio bus lock events per second
are way beyond the point where the machine does anything else than being
stuck in buslocks.
Aside of that why are you trying to make this throttling in any way
accurate? It does not matter at all, really. Limit reached, put it to
sleep for some time and be done with it. No point in trying to be clever
for no value.
Thanks,
tglx
next prev parent reply other threads:[~2021-04-12 7:15 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-13 5:49 [PATCH v5 0/3] x86/bus_lock: Enable bus lock detection Fenghua Yu
2021-03-13 5:49 ` [PATCH v5 1/3] x86/cpufeatures: Enumerate #DB for " Fenghua Yu
2021-03-19 20:35 ` Thomas Gleixner
2021-03-19 21:00 ` Fenghua Yu
2021-03-13 5:49 ` [PATCH v5 2/3] x86/bus_lock: Handle #DB for bus lock Fenghua Yu
2021-03-19 21:30 ` Thomas Gleixner
2021-03-19 21:50 ` Luck, Tony
2021-03-20 1:01 ` Thomas Gleixner
2021-03-20 13:57 ` Thomas Gleixner
2021-04-03 0:50 ` Fenghua Yu
2021-03-19 22:19 ` Fenghua Yu
2021-03-20 12:42 ` Thomas Gleixner
2021-04-03 1:04 ` Fenghua Yu
2021-04-12 7:15 ` Thomas Gleixner [this message]
2021-04-13 23:40 ` Fenghua Yu
2021-04-14 9:41 ` Thomas Gleixner
2021-03-13 5:49 ` [PATCH v5 3/3] Documentation/admin-guide: Change doc for split_lock_detect parameter Fenghua Yu
2021-03-19 21:35 ` Thomas Gleixner
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=8735vw2cub.ffs@nanos.tec.linutronix.de \
--to=tglx@linutronix.de \
--cc=bp@alien8.de \
--cc=fenghua.yu@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=ravi.v.shankar@intel.com \
--cc=rdunlap@infradead.org \
--cc=tony.luck@intel.com \
--cc=x86@kernel.org \
--cc=xiaoyao.li@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;
as well as URLs for NNTP newsgroup(s).