From: Dave Hansen <dave.hansen@intel.com>
To: Zhang Rui <rui.zhang@intel.com>, Feng Tang <feng.tang@intel.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
"H . Peter Anvin" <hpa@zytor.com>,
Peter Zijlstra <peterz@infradead.org>,
x86@kernel.org, linux-kernel@vger.kernel.org
Cc: tim.c.chen@intel.com, Xiongfeng Wang <wangxiongfeng2@huawei.com>,
liaoyu15@huawei.com
Subject: Re: [PATCH v1 1/2] x86/tsc: use logical_package as a better estimation of socket numbers
Date: Mon, 24 Oct 2022 08:42:30 -0700 [thread overview]
Message-ID: <dfd2fb43-2a19-545a-fea8-f793a685ef30@intel.com> (raw)
In-Reply-To: <6636557f617ea5a1a1ab6f30f7aea0ececdd2a36.camel@intel.com>
On 10/22/22 09:12, Zhang Rui wrote:
>>> I'm not sure if we have a perfect solution here.
>> Are the implementations fixable?
> currently, I don't have any idea.
>
>> Or, at least tolerable?
That would be great to figure out before we start throwing more patches
around.
>> For instance, I can live with the implementation being a bit goofy
>> when
>> kernel commandlines are in play. We can pr_info() about those cases.
> My understanding is that the cpus in the last package may still have
> small cpu id value. This means that the 'logical_packages' is hard to
> break unless we boot with very small CPU count and happened to disable
> all cpus in one/more packages. Feng is experiencing with this and may
> have some update later.
>
> If this is the case, is this a valid case that we need to take care of?
Well, let's talk through it a bit.
What is the triggering event and what's the fallout?
Is the user on a truly TSC stable system or not?
What kind of maxcpus= argument do they need to specify? Is it something
that's likely to get used in production or is it most likely just for
debugging?
What is the maxcpus= fallout? Does it over estimate or under estimate
the number of logical packages?
How many cases outside of maxcpus= do we know of that lead to an
imprecise "logical packages" calculation?
Does this lead to the TSC being mistakenly marked stable when it is not,
or *not* being marked stable when it is?
Let's get all of that info in one place and make sure we are all agreed
on the *problem* before we got to the solution space.
next prev parent reply other threads:[~2022-10-24 17:09 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-21 6:21 [PATCH v1 1/2] x86/tsc: use logical_package as a better estimation of socket numbers Feng Tang
2022-10-21 6:21 ` [PATCH v1 2/2] x86/tsc: Extend watchdog check exemption to 4-Sockets platform Feng Tang
2023-06-02 18:00 ` Paul E. McKenney
2023-06-05 6:28 ` Feng Tang
2022-10-21 15:00 ` [PATCH v1 1/2] x86/tsc: use logical_package as a better estimation of socket numbers Zhang Rui
2022-10-21 16:21 ` Dave Hansen
2022-10-22 16:12 ` Zhang Rui
2022-10-24 15:42 ` Dave Hansen [this message]
2022-10-25 7:35 ` Feng Tang
2022-10-24 7:37 ` Feng Tang
2022-10-24 15:43 ` Dave Hansen
2022-10-25 7:57 ` Feng Tang
2022-11-04 7:21 ` Feng Tang
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=dfd2fb43-2a19-545a-fea8-f793a685ef30@intel.com \
--to=dave.hansen@intel.com \
--cc=bp@alien8.de \
--cc=feng.tang@intel.com \
--cc=hpa@zytor.com \
--cc=liaoyu15@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=rui.zhang@intel.com \
--cc=tglx@linutronix.de \
--cc=tim.c.chen@intel.com \
--cc=wangxiongfeng2@huawei.com \
--cc=x86@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.