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: Wed, 14 Apr 2021 11:41:28 +0200 [thread overview]
Message-ID: <875z0pxkxj.ffs@nanos.tec.linutronix.de> (raw)
In-Reply-To: <YHYr/cK+8BGXNILt@otcwcpicx3.sc.intel.com>
Fenghua,
On Tue, Apr 13 2021 at 23:40, Fenghua Yu wrote:
> On Mon, Apr 12, 2021 at 09:15:08AM +0200, Thomas Gleixner wrote:
>> 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.
>
> Is it OK to set bld_ratelimit between 1 and 1,000 bus locks/sec for
> bld_ratelimit?
>
> Can I do the throttling like this?
>
> /* Enforce no more than bld_ratelimit bus locks/sec. */
> while (!__ratelimit(&global_bld_ratelimit))
> msleep(10);
>
> On one machine, if bld_ratelimit=1,000, that's about 5msec for a busy
> bus lock loop, i.e. bus is locked for about 5msec and then the process
> sleeps for 10msec and thus won't generate any bus lock.
> "dd" command running on other cores doesn't have noticeable degradation
> with bld_ratelimit=1,000.
Something like this makes sense. Add some rationale for the upper limit
you finally end up with so sysadmins can make informed decisions.
Thanks,
tglx
next prev parent reply other threads:[~2021-04-14 9:41 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
2021-04-13 23:40 ` Fenghua Yu
2021-04-14 9:41 ` Thomas Gleixner [this message]
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=875z0pxkxj.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).