From: Thomas Gleixner <tglx@linutronix.de>
To: Yury Norov <yury.norov@gmail.com>
Cc: linux-kernel@vger.kernel.org,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Paul E. McKenney" <paulmck@kernel.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Anna-Maria Behnsen <anna-maria@linutronix.de>,
Ben Segall <bsegall@google.com>,
Daniel Bristot de Oliveira <bristot@redhat.com>,
Dietmar Eggemann <dietmar.eggemann@arm.com>,
Frederic Weisbecker <frederic@kernel.org>,
Imran Khan <imran.f.khan@oracle.com>,
Ingo Molnar <mingo@redhat.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Juri Lelli <juri.lelli@redhat.com>,
Leonardo Bras <leobras@redhat.com>, Mel Gorman <mgorman@suse.de>,
Peter Zijlstra <peterz@infradead.org>,
Rik van Riel <riel@surriel.com>,
Steven Rostedt <rostedt@goodmis.org>, Tejun Heo <tj@kernel.org>,
Valentin Schneider <vschneid@redhat.com>,
Vincent Guittot <vincent.guittot@linaro.org>,
Waiman Long <longman@redhat.com>,
Zefan Li <lizefan.x@bytedance.com>,
cgroups@vger.kernel.org
Subject: Re: [PATCH 6/6] tick/common: optimize cpumask_equal() usage
Date: Tue, 14 May 2024 22:47:57 +0200 [thread overview]
Message-ID: <87msosktmq.ffs@tglx> (raw)
In-Reply-To: <CAAH8bW-o_zz_C_NFnjL3uP1BXyC4OF-BAR2Dk2Xd-DFDOZpodQ@mail.gmail.com>
On Tue, May 14 2024 at 09:47, Yury Norov wrote:
>> Instead of sprinkling these conditional all over the place, can't you
>> just do the obvious and check for ptr1 == ptr2 in bitmap_copy() and
>> bitmap_equal()?
>
> I proposed this a while (few years) ago, and it has been rejected. On
> bitmaps level we decided not to do that for the reasons memcpy() and
> memcmp() doesn't, and on cpumasks and nodemasks level it hasn't
> been discussed at all.
>
> Now that most of bitmap ops have inline and outline implementation,
> we technically can move this checks in outline code, as inline bitmap
> ops are very lightweight already.
>
> So I see the following options:
> - Implement these sanity checks in outline bitmap API (lib/bitmap.c);
> - Implement them on cpumask and nodemask level; or
> - add a new family of helpers that do this check, like
> bitmap_copy_if_needed() (better name appreciated).
>
> The argument against #1 and #2 these days was that memcpy() and
> similarly bitmap_copy() with dst == src may be a sign of error, and
> we don't want to add a code that optimizes for it.
That's a fair argument.
> Now, I ran the kernel through the LTP test and in practice all the
> cases that I spot look pretty normal. So I can continue sprinkling
> the checks once a few years, or do something like described above.
I don't see these checks as valuable in most cases and I detest them as
they make the code harder to read.
Except for smp_call_function_many_cond() and to a lesser extent
irq_do_set_affinity() none of them you added really matters.
Though it might be worth to have helper functions which make it obvious
that the src == dst case is intentional.
Thanks,
tglx
prev parent reply other threads:[~2024-05-14 20:48 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-13 22:01 [PATCH 0/6] bitmap: optimize API usage Yury Norov
2024-05-13 22:01 ` [PATCH 1/6] smp: optimize smp_call_function_many_cond() Yury Norov
2024-05-13 22:01 ` [PATCH 2/6] sched/topology: optimize topology_span_sane() Yury Norov
2024-05-14 20:53 ` Christophe JAILLET
2024-07-31 19:52 ` Leonardo Bras
2024-05-13 22:01 ` [PATCH 3/6] driver core: cpu: optimize print_cpus_isolated() Yury Norov
2024-05-14 21:02 ` Thomas Gleixner
2024-05-13 22:01 ` [PATCH 4/6] genirq: optimize irq_do_set_affinity() Yury Norov
2024-05-14 12:51 ` Jinjie Ruan
2024-05-14 16:16 ` Yury Norov
2024-05-13 22:01 ` [PATCH 5/6] cgroup/cpuset: optimize cpuset_mems_allowed_intersects() Yury Norov
2024-05-14 16:47 ` Waiman Long
2024-05-14 16:50 ` Tejun Heo
2024-05-14 16:55 ` Waiman Long
2024-05-13 22:01 ` [PATCH 6/6] tick/common: optimize cpumask_equal() usage Yury Norov
2024-05-14 8:31 ` Thomas Gleixner
2024-05-14 8:42 ` Thomas Gleixner
2024-05-14 16:47 ` Yury Norov
2024-05-14 20:47 ` Thomas Gleixner [this message]
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=87msosktmq.ffs@tglx \
--to=tglx@linutronix.de \
--cc=anna-maria@linutronix.de \
--cc=bristot@redhat.com \
--cc=bsegall@google.com \
--cc=cgroups@vger.kernel.org \
--cc=dietmar.eggemann@arm.com \
--cc=frederic@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=hannes@cmpxchg.org \
--cc=imran.f.khan@oracle.com \
--cc=juri.lelli@redhat.com \
--cc=leobras@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lizefan.x@bytedance.com \
--cc=longman@redhat.com \
--cc=mgorman@suse.de \
--cc=mingo@redhat.com \
--cc=paulmck@kernel.org \
--cc=peterz@infradead.org \
--cc=rafael@kernel.org \
--cc=riel@surriel.com \
--cc=rostedt@goodmis.org \
--cc=tj@kernel.org \
--cc=vincent.guittot@linaro.org \
--cc=vschneid@redhat.com \
--cc=yury.norov@gmail.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 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.