cgroups.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

      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 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).