From: Gregory Price <gourry@gourry.net>
To: Dan Carpenter <dan.carpenter@linaro.org>
Cc: Joshua Hahn <joshua.hahnjy@gmail.com>, linux-mm@kvack.org
Subject: Re: [bug report] mm/mempolicy: Weighted Interleave Auto-tuning
Date: Tue, 18 Feb 2025 11:41:31 -0500 [thread overview]
Message-ID: <Z7S4O6ThYDSGh49W@gourry-fedora-PF4VCD3F> (raw)
In-Reply-To: <547331c1-5332-432b-83f0-911b96a79d72@stanley.mountain>
On Mon, Feb 17, 2025 at 10:35:20AM +0300, Dan Carpenter wrote:
> Hello Joshua Hahn,
>
> Commit aab5f6eb05fd ("mm/mempolicy: Weighted Interleave Auto-tuning")
> from Feb 7, 2025 (linux-next), leads to the following Smatch static
> checker warning:
>
> mm/mempolicy.c:220 mempolicy_set_node_perf()
> warn: assigned value is less than '1844674407370955161'
>
> mm/mempolicy.c
> 209 int mempolicy_set_node_perf(unsigned int node, struct access_coordinate *coords)
> 210 {
> 211 uint64_t *old_bw, *new_bw;
> 212 uint64_t bw_val;
> 213 u8 *old_iw, *new_iw;
> 214
> 215 /*
> 216 * Bandwidths above this limit cause rounding errors when reducing
> 217 * weights. This value is ~16 exabytes, which is unreasonable anyways.
>
> I see this comment about exabytes
>
> 218 */
> 219 bw_val = min(coords->read_bandwidth, coords->write_bandwidth);
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> but these values are u32s
>
> --> 220 if (bw_val > (U64_MAX / 10))
> ^^^^^^^^^^^^
> There is no way they're going to be more than U64_MAX / 10.
>
hm, not sure why we thought these were u64.
Anyway, agreed, pointless check since the condition can't be met.
It's possible we wanted to apply this to sum_bw instead.
Will take a look.
~Gregory
next prev parent reply other threads:[~2025-02-18 16:41 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-17 7:35 Dan Carpenter
2025-02-18 16:41 ` Gregory Price [this message]
2025-02-18 18:31 ` Joshua Hahn
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=Z7S4O6ThYDSGh49W@gourry-fedora-PF4VCD3F \
--to=gourry@gourry.net \
--cc=dan.carpenter@linaro.org \
--cc=joshua.hahnjy@gmail.com \
--cc=linux-mm@kvack.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox