public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* [RFC PATCH 0/2] Introduce cpumask_first_but() and use cases
@ 2025-06-13  3:34 I Hsin Cheng
  2025-06-13  3:34 ` [RFC PATCH 1/2] cpumask: Introduce cpumask_first_but() I Hsin Cheng
  2025-06-13  3:34 ` [RFC PATCH 2/2] clocksource: Use cpumask_first_but() in clocksource_verify_choose_cpus() I Hsin Cheng
  0 siblings, 2 replies; 14+ messages in thread
From: I Hsin Cheng @ 2025-06-13  3:34 UTC (permalink / raw)
  To: yury.norov
  Cc: linux, jstultz, tglx, sboyd, linux-kernel, eleanor15x, visitorckw,
	jserv, skhan, linux-kernel-mentees, I Hsin Cheng

This series introduce cpumask_first_but() and make cpumask_any_but()
a wrapper around it, just like other cpumask_any*() helpers, they're
some wrappers around cpumask_first*(), except some special cases.

The patches are scheduled as the following:
1. The implementation of cpumask_first_but() and some
positive results of making cpumask_any_but() a wrapper around
it are attached there, including performance and code size.

2. Use cpumask_first_but() in clocksource


I Hsin Cheng (2):
  cpumask: Introduce cpumask_first_but()
  clocksource: Use cpumask_first_but() in
    clocksource_verify_choose_cpus()

 include/linux/cpumask.h   | 22 ++++++++++++++++------
 kernel/time/clocksource.c |  4 +---
 2 files changed, 17 insertions(+), 9 deletions(-)

-- 
2.43.0


^ permalink raw reply	[flat|nested] 14+ messages in thread

* [RFC PATCH 1/2] cpumask: Introduce cpumask_first_but()
  2025-06-13  3:34 [RFC PATCH 0/2] Introduce cpumask_first_but() and use cases I Hsin Cheng
@ 2025-06-13  3:34 ` I Hsin Cheng
  2025-06-13  5:55   ` Kuan-Wei Chiu
  2025-06-13  3:34 ` [RFC PATCH 2/2] clocksource: Use cpumask_first_but() in clocksource_verify_choose_cpus() I Hsin Cheng
  1 sibling, 1 reply; 14+ messages in thread
From: I Hsin Cheng @ 2025-06-13  3:34 UTC (permalink / raw)
  To: yury.norov
  Cc: linux, jstultz, tglx, sboyd, linux-kernel, eleanor15x, visitorckw,
	jserv, skhan, linux-kernel-mentees, I Hsin Cheng

Switch the implementation of cpumask_any_but() to cpumask_first_but().
Elimate the need to looping and make cpumask_any_but() a macro to wrap
around cpumask_first_but(), just like cpumask_any() does, to make it
more consistence.

The change brings some benefit in terms of code size shrinking of
vmlinux, for NR_CPUS=64, it reduce 78 bytes in total, for
NR_CPUS=4096, it reduce 2 bytes in total. The details are shown in the
table [1].

Performance test is done using the test script [2]. Running the test for
10000 times, the origin implementation of cpumask_any_but() use 19665287
nanoseconds in total, the new version of it, which is a wrapper around
cpumask_first_but(), uses 19545574 nanoseconds. The difference is 119713
nanoseconds.

Co-developed-by: Yu-Chun Lin <eleanor15x@gmail.com>
Signed-off-by: Yu-Chun Lin <eleanor15x@gmail.com>
Signed-off-by: Kuan-Wei Chiu <visitorckw@gmail.com>
Signed-off-by: I Hsin Cheng <richard120310@gmail.com>
---
[1]:

For NR_CPUS=64:
$ ./scripts/bloat-o-meter vmlinux_old vmlinux_new
add/remove: 0/0 grow/shrink: 3/7 up/down: 46/-124 (-78)
Function                                     old     new   delta
irq_migrate_all_off_this_cpu                 716     745     +29
try_to_unmap_one                            3380    3391     +11
try_to_migrate_one                          2451    2457      +6
uncore_event_cpu_offline                     343     342      -1
calibrate_delay_is_known                     236     235      -1
tsc_store_and_check_tsc_adjust               506     495     -11
arch_tlbbatch_flush                          302     288     -14
tmigr_cpu_offline                            406     382     -24
perf_event_exit_cpu_context                  592     565     -27
flush_tlb_mm_range                          1561    1515     -46
Total: Before=23390770, After=23390692, chg -0.00%

For NR_CPUS=4096:
$ ./scripts/bloat-o-meter vmlinux_old vmlinux_new
add/remove: 0/0 grow/shrink: 7/3 up/down: 136/-138 (-2)
Function                                     old     new   delta
uncore_event_cpu_offline                     291     333     +42
try_to_migrate_one                          2378    2413     +35
flush_tlb_mm_range                          1476    1503     +27
irq_migrate_all_off_this_cpu                 741     754     +13
tmigr_cpu_offline                            353     362      +9
calibrate_delay_is_known                     183     192      +9
arch_tlbbatch_flush                          296     297      +1
tsc_store_and_check_tsc_adjust               484     482      -2
perf_event_exit_cpu_context                  546     528     -18
try_to_unmap_one                            3560    3442    -118
Total: Before=23448698, After=23448696, chg -0.00%

[2]:
static int __init test_init(void)
{
    struct cpumask test_mask;
    ktime_t start_time, end_time;
    s64 elapsed_ns;
    unsigned int result;
    unsigned int random_cpu;
    int i;

    cpumask_copy(&test_mask, cpu_online_mask);

    start_time = ktime_get();

    for (i = 0; i < 100000; i++) {
        get_random_bytes(&random_cpu, sizeof(random_cpu));
        random_cpu = random_cpu % nr_cpu_ids;
        result = cpumask_any_but(&test_mask, random_cpu);
    }

    end_time = ktime_get();

    elapsed_ns = ktime_to_ns(ktime_sub(end_time, start_time));

	pr_info("Total time: %lld ns\n", elapsed_ns);

    return 0;
}

The test is running in the form of kernel module.
The test machine is running ubuntu 24.04 on x86_64 machine with kernel
version of v6.14.0, CPU type is AMD Ryzen 7 5700X3D 8-Core Processor.

Best regards,
I Hsin Cheng
---
 include/linux/cpumask.h | 22 ++++++++++++++++------
 1 file changed, 16 insertions(+), 6 deletions(-)

diff --git a/include/linux/cpumask.h b/include/linux/cpumask.h
index f9a868384083..d91630a97d76 100644
--- a/include/linux/cpumask.h
+++ b/include/linux/cpumask.h
@@ -408,22 +408,22 @@ unsigned int cpumask_next_wrap(int n, const struct cpumask *src)
 	for_each_set_bit_from(cpu, cpumask_bits(mask), small_cpumask_bits)
 
 /**
- * cpumask_any_but - return an arbitrary cpu in a cpumask, but not this one.
+ * cpumask_first_but - return the first cpu in a cpumask, but not this one.
  * @mask: the cpumask to search
  * @cpu: the cpu to ignore.
  *
- * Often used to find any cpu but smp_processor_id() in a mask.
+ * Often used to find the first cpu but smp_processor_id() in a mask.
  * Return: >= nr_cpu_ids if no cpus set.
  */
 static __always_inline
-unsigned int cpumask_any_but(const struct cpumask *mask, unsigned int cpu)
+unsigned int cpumask_first_but(const struct cpumask *mask, unsigned int cpu)
 {
 	unsigned int i;
 
 	cpumask_check(cpu);
-	for_each_cpu(i, mask)
-		if (i != cpu)
-			break;
+	i = cpumask_first(mask);
+	if (i == cpu)
+		i = cpumask_next(i, mask);
 	return i;
 }
 
@@ -864,6 +864,16 @@ void cpumask_copy(struct cpumask *dstp, const struct cpumask *srcp)
  */
 #define cpumask_any(srcp) cpumask_first(srcp)
 
+/**
+ * cpumask_any_but - pick an arbitrary cpu from *srcp but not the given cpu
+ * @srcp: the input cpumask
+ * @cpu: the cpu to ignore
+ *
+ * Often used to find any cpu but smp_processor_id() in a mask.
+ * Return: >= nr_cpu_ids if no cpus set.
+ */
+#define cpumask_any_but(srcp, cpu) cpumask_first_but(srcp, cpu)
+
 /**
  * cpumask_any_and - pick an arbitrary cpu from *mask1 & *mask2
  * @mask1: the first input cpumask
-- 
2.43.0


^ permalink raw reply related	[flat|nested] 14+ messages in thread

* [RFC PATCH 2/2] clocksource: Use cpumask_first_but() in clocksource_verify_choose_cpus()
  2025-06-13  3:34 [RFC PATCH 0/2] Introduce cpumask_first_but() and use cases I Hsin Cheng
  2025-06-13  3:34 ` [RFC PATCH 1/2] cpumask: Introduce cpumask_first_but() I Hsin Cheng
@ 2025-06-13  3:34 ` I Hsin Cheng
  2025-06-13  5:02   ` Yury Norov
  1 sibling, 1 reply; 14+ messages in thread
From: I Hsin Cheng @ 2025-06-13  3:34 UTC (permalink / raw)
  To: yury.norov
  Cc: linux, jstultz, tglx, sboyd, linux-kernel, eleanor15x, visitorckw,
	jserv, skhan, linux-kernel-mentees, I Hsin Cheng

Utilize cpumask_first_but() helper instead of first using
cpumask_first() and then cpumask_next(). The logic is the same here,
using the new helper will make it more conscious.

Use bloat-o-meter to check the impact on code size, the result is the
same, does not have positive impact nor negative impact.

$ ./scripts/bloat-o-meter vmlinux_old vmlinux_new
add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0)
Function                                     old     new   delta
Total: Before=22590709, After=22590709, chg +0.00%

Signed-off-by: I Hsin Cheng <richard120310@gmail.com>
---
Generally speaking, I think this is just a small tweak on the code,
making it more readable. However, no benefit in code size or performance
as the implementation behind the helper is in fact the same as the one
used here.

Maybe more tests should be done to ensure the change is solid, I hope to
seek some suggestions from everyone who has any ideas, or this is enough
then it's good.

Best regards,
I Hsin Cheng
---
 kernel/time/clocksource.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/kernel/time/clocksource.c b/kernel/time/clocksource.c
index bb48498ebb5a..12ff0c048570 100644
--- a/kernel/time/clocksource.c
+++ b/kernel/time/clocksource.c
@@ -323,9 +323,7 @@ static void clocksource_verify_choose_cpus(void)
 		return;
 
 	/* Make sure to select at least one CPU other than the current CPU. */
-	cpu = cpumask_first(cpu_online_mask);
-	if (cpu == smp_processor_id())
-		cpu = cpumask_next(cpu, cpu_online_mask);
+	cpu = cpumask_first_but(cpu_online_mask, smp_processor_id());
 	if (WARN_ON_ONCE(cpu >= nr_cpu_ids))
 		return;
 	cpumask_set_cpu(cpu, &cpus_chosen);
-- 
2.43.0


^ permalink raw reply related	[flat|nested] 14+ messages in thread

* Re: [RFC PATCH 2/2] clocksource: Use cpumask_first_but() in clocksource_verify_choose_cpus()
  2025-06-13  3:34 ` [RFC PATCH 2/2] clocksource: Use cpumask_first_but() in clocksource_verify_choose_cpus() I Hsin Cheng
@ 2025-06-13  5:02   ` Yury Norov
  2025-06-13  5:22     ` I Hsin Cheng
                       ` (3 more replies)
  0 siblings, 4 replies; 14+ messages in thread
From: Yury Norov @ 2025-06-13  5:02 UTC (permalink / raw)
  To: I Hsin Cheng
  Cc: linux, jstultz, tglx, sboyd, linux-kernel, eleanor15x, visitorckw,
	jserv, skhan, linux-kernel-mentees

I Hsin,

This exact change has already been submitted by me and is under review.

https://lore.kernel.org/all/20250604232550.40491-2-yury.norov@gmail.com/

I don't understand why are you undercutting my work, and moreover do it 
for the second time.

For the first time you submitted something that duplicates my another
patch from the exact same series. John Stultz has pointed that, so you're
surely aware.

https://lore.kernel.org/all/CANDhNCoJ_MmpEfyuL+JWav+NUfQDH3dm196JSE-Mv3QrPUzi3g@mail.gmail.com/

Kernel development process implies that one makes sure that his work
is unique and doesn't break someone else's development, at one's best
knowledge.

What you're doing not only breaks this rule. You're in fact trying to
get credit for the work that is done by someone else. This is the
definition of fraud.

I cannot make sure that any other patches from you are unique and
written by actually you. Therefore, I will not take your work anymore.

I encourage everyone else to be careful working with I Hsing Cheng
and check his patches for uniqueness, at minimum.  

NAKed-by: Yury Norov <yury.norov@gmail.com>

Thanks,
Yury

On Fri, Jun 13, 2025 at 11:34:47AM +0800, I Hsin Cheng wrote:
> Utilize cpumask_first_but() helper instead of first using
> cpumask_first() and then cpumask_next(). The logic is the same here,
> using the new helper will make it more conscious.
> 
> Use bloat-o-meter to check the impact on code size, the result is the
> same, does not have positive impact nor negative impact.
> 
> $ ./scripts/bloat-o-meter vmlinux_old vmlinux_new
> add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0)
> Function                                     old     new   delta
> Total: Before=22590709, After=22590709, chg +0.00%
> 
> Signed-off-by: I Hsin Cheng <richard120310@gmail.com>
> ---
> Generally speaking, I think this is just a small tweak on the code,
> making it more readable. However, no benefit in code size or performance
> as the implementation behind the helper is in fact the same as the one
> used here.
> 
> Maybe more tests should be done to ensure the change is solid, I hope to
> seek some suggestions from everyone who has any ideas, or this is enough
> then it's good.
> 
> Best regards,
> I Hsin Cheng
> ---
>  kernel/time/clocksource.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/kernel/time/clocksource.c b/kernel/time/clocksource.c
> index bb48498ebb5a..12ff0c048570 100644
> --- a/kernel/time/clocksource.c
> +++ b/kernel/time/clocksource.c
> @@ -323,9 +323,7 @@ static void clocksource_verify_choose_cpus(void)
>  		return;
>  
>  	/* Make sure to select at least one CPU other than the current CPU. */
> -	cpu = cpumask_first(cpu_online_mask);
> -	if (cpu == smp_processor_id())
> -		cpu = cpumask_next(cpu, cpu_online_mask);
> +	cpu = cpumask_first_but(cpu_online_mask, smp_processor_id());
>  	if (WARN_ON_ONCE(cpu >= nr_cpu_ids))
>  		return;
>  	cpumask_set_cpu(cpu, &cpus_chosen);
> -- 
> 2.43.0

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [RFC PATCH 2/2] clocksource: Use cpumask_first_but() in clocksource_verify_choose_cpus()
  2025-06-13  5:02   ` Yury Norov
@ 2025-06-13  5:22     ` I Hsin Cheng
  2025-06-16 14:34       ` Shuah Khan
  2025-06-13  5:41     ` I Hsin Cheng
                       ` (2 subsequent siblings)
  3 siblings, 1 reply; 14+ messages in thread
From: I Hsin Cheng @ 2025-06-13  5:22 UTC (permalink / raw)
  To: Yury Norov
  Cc: linux, jstultz, tglx, sboyd, linux-kernel, eleanor15x, visitorckw,
	jserv, skhan, linux-kernel-mentees

On Fri, Jun 13, 2025 at 01:02:38AM -0400, Yury Norov wrote:
> I Hsin,
> 
> This exact change has already been submitted by me and is under review.
> 
> https://lore.kernel.org/all/20250604232550.40491-2-yury.norov@gmail.com/
> 
> I don't understand why are you undercutting my work, and moreover do it 
> for the second time.
> 
> For the first time you submitted something that duplicates my another
> patch from the exact same series. John Stultz has pointed that, so you're
> surely aware.
> 
> https://lore.kernel.org/all/CANDhNCoJ_MmpEfyuL+JWav+NUfQDH3dm196JSE-Mv3QrPUzi3g@mail.gmail.com/
> 
> Kernel development process implies that one makes sure that his work
> is unique and doesn't break someone else's development, at one's best
> knowledge.
> 
> What you're doing not only breaks this rule. You're in fact trying to
> get credit for the work that is done by someone else. This is the
> definition of fraud.
> 
> I cannot make sure that any other patches from you are unique and
> written by actually you. Therefore, I will not take your work anymore.
> 
> I encourage everyone else to be careful working with I Hsing Cheng
> and check his patches for uniqueness, at minimum.  
> 
> NAKed-by: Yury Norov <yury.norov@gmail.com>
> 
> Thanks,
> Yury
>

Hello Yury,

Sorry to make troubles, I didn't mean to do this, I wasn't aware that
you've send the same work and nor do I mean to interrupt your work. I
didn't have the habit to check others patches regularly, I'm sorry for
that.

I just saw Kuan-Wei's patch from months ago and I asked him whether I
can continue that work, and he agrees, so I try to do something from
there.

Again sorry for causing troubles, I'll make sure to look for others
patches first before submitting them.

Sincerely sorry for this.

Thanks,
I Hsin Cheng

> On Fri, Jun 13, 2025 at 11:34:47AM +0800, I Hsin Cheng wrote:
> > Utilize cpumask_first_but() helper instead of first using
> > cpumask_first() and then cpumask_next(). The logic is the same here,
> > using the new helper will make it more conscious.
> > 
> > Use bloat-o-meter to check the impact on code size, the result is the
> > same, does not have positive impact nor negative impact.
> > 
> > $ ./scripts/bloat-o-meter vmlinux_old vmlinux_new
> > add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0)
> > Function                                     old     new   delta
> > Total: Before=22590709, After=22590709, chg +0.00%
> > 
> > Signed-off-by: I Hsin Cheng <richard120310@gmail.com>
> > ---
> > Generally speaking, I think this is just a small tweak on the code,
> > making it more readable. However, no benefit in code size or performance
> > as the implementation behind the helper is in fact the same as the one
> > used here.
> > 
> > Maybe more tests should be done to ensure the change is solid, I hope to
> > seek some suggestions from everyone who has any ideas, or this is enough
> > then it's good.
> > 
> > Best regards,
> > I Hsin Cheng
> > ---
> >  kernel/time/clocksource.c | 4 +---
> >  1 file changed, 1 insertion(+), 3 deletions(-)
> > 
> > diff --git a/kernel/time/clocksource.c b/kernel/time/clocksource.c
> > index bb48498ebb5a..12ff0c048570 100644
> > --- a/kernel/time/clocksource.c
> > +++ b/kernel/time/clocksource.c
> > @@ -323,9 +323,7 @@ static void clocksource_verify_choose_cpus(void)
> >  		return;
> >  
> >  	/* Make sure to select at least one CPU other than the current CPU. */
> > -	cpu = cpumask_first(cpu_online_mask);
> > -	if (cpu == smp_processor_id())
> > -		cpu = cpumask_next(cpu, cpu_online_mask);
> > +	cpu = cpumask_first_but(cpu_online_mask, smp_processor_id());
> >  	if (WARN_ON_ONCE(cpu >= nr_cpu_ids))
> >  		return;
> >  	cpumask_set_cpu(cpu, &cpus_chosen);
> > -- 
> > 2.43.0

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [RFC PATCH 2/2] clocksource: Use cpumask_first_but() in clocksource_verify_choose_cpus()
  2025-06-13  5:02   ` Yury Norov
  2025-06-13  5:22     ` I Hsin Cheng
@ 2025-06-13  5:41     ` I Hsin Cheng
  2025-06-13  6:00     ` I Hsin Cheng
  2025-06-13 10:48     ` Thomas Gleixner
  3 siblings, 0 replies; 14+ messages in thread
From: I Hsin Cheng @ 2025-06-13  5:41 UTC (permalink / raw)
  To: Yury Norov
  Cc: linux, jstultz, tglx, sboyd, linux-kernel, eleanor15x, visitorckw,
	jserv, skhan, linux-kernel-mentees

On Fri, Jun 13, 2025 at 01:02:38AM -0400, Yury Norov wrote:
> I Hsin,
> 
> This exact change has already been submitted by me and is under review.
> 
> https://lore.kernel.org/all/20250604232550.40491-2-yury.norov@gmail.com/
> 
> I don't understand why are you undercutting my work, and moreover do it 
> for the second time.
> 
> For the first time you submitted something that duplicates my another
> patch from the exact same series. John Stultz has pointed that, so you're
> surely aware.
> 
> https://lore.kernel.org/all/CANDhNCoJ_MmpEfyuL+JWav+NUfQDH3dm196JSE-Mv3QrPUzi3g@mail.gmail.com/
> 
> Kernel development process implies that one makes sure that his work
> is unique and doesn't break someone else's development, at one's best
> knowledge.
> 
> What you're doing not only breaks this rule. You're in fact trying to
> get credit for the work that is done by someone else. This is the
> definition of fraud.
> 
> I cannot make sure that any other patches from you are unique and
> written by actually you. Therefore, I will not take your work anymore.
> 
> I encourage everyone else to be careful working with I Hsing Cheng
> and check his patches for uniqueness, at minimum.  
> 
> NAKed-by: Yury Norov <yury.norov@gmail.com>
> 
> Thanks,
> Yury
>

Hello Yury,

Sorry again, just like I mentioned in another thread, I didn't check the
patch 1 of your patch series, I'm really sorry for that and causing your
trouble.

I really have no offense on that, the motivation of this patch was just
like I mentioned earlier, anyway sorry for not be careful enough and 
interrupt your work.
Hope you can forgive me this time.

Best regards,
I Hsin Cheng

> On Fri, Jun 13, 2025 at 11:34:47AM +0800, I Hsin Cheng wrote:
> > Utilize cpumask_first_but() helper instead of first using
> > cpumask_first() and then cpumask_next(). The logic is the same here,
> > using the new helper will make it more conscious.
> > 
> > Use bloat-o-meter to check the impact on code size, the result is the
> > same, does not have positive impact nor negative impact.
> > 
> > $ ./scripts/bloat-o-meter vmlinux_old vmlinux_new
> > add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0)
> > Function                                     old     new   delta
> > Total: Before=22590709, After=22590709, chg +0.00%
> > 
> > Signed-off-by: I Hsin Cheng <richard120310@gmail.com>
> > ---
> > Generally speaking, I think this is just a small tweak on the code,
> > making it more readable. However, no benefit in code size or performance
> > as the implementation behind the helper is in fact the same as the one
> > used here.
> > 
> > Maybe more tests should be done to ensure the change is solid, I hope to
> > seek some suggestions from everyone who has any ideas, or this is enough
> > then it's good.
> > 
> > Best regards,
> > I Hsin Cheng
> > ---
> >  kernel/time/clocksource.c | 4 +---
> >  1 file changed, 1 insertion(+), 3 deletions(-)
> > 
> > diff --git a/kernel/time/clocksource.c b/kernel/time/clocksource.c
> > index bb48498ebb5a..12ff0c048570 100644
> > --- a/kernel/time/clocksource.c
> > +++ b/kernel/time/clocksource.c
> > @@ -323,9 +323,7 @@ static void clocksource_verify_choose_cpus(void)
> >  		return;
> >  
> >  	/* Make sure to select at least one CPU other than the current CPU. */
> > -	cpu = cpumask_first(cpu_online_mask);
> > -	if (cpu == smp_processor_id())
> > -		cpu = cpumask_next(cpu, cpu_online_mask);
> > +	cpu = cpumask_first_but(cpu_online_mask, smp_processor_id());
> >  	if (WARN_ON_ONCE(cpu >= nr_cpu_ids))
> >  		return;
> >  	cpumask_set_cpu(cpu, &cpus_chosen);
> > -- 
> > 2.43.0

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [RFC PATCH 1/2] cpumask: Introduce cpumask_first_but()
  2025-06-13  3:34 ` [RFC PATCH 1/2] cpumask: Introduce cpumask_first_but() I Hsin Cheng
@ 2025-06-13  5:55   ` Kuan-Wei Chiu
  0 siblings, 0 replies; 14+ messages in thread
From: Kuan-Wei Chiu @ 2025-06-13  5:55 UTC (permalink / raw)
  To: I Hsin Cheng
  Cc: yury.norov, linux, jstultz, tglx, sboyd, linux-kernel, eleanor15x,
	jserv, skhan, linux-kernel-mentees

On Fri, Jun 13, 2025 at 11:34:46AM +0800, I Hsin Cheng wrote:
> Switch the implementation of cpumask_any_but() to cpumask_first_but().
> Elimate the need to looping and make cpumask_any_but() a macro to wrap
> around cpumask_first_but(), just like cpumask_any() does, to make it
> more consistence.
> 
> The change brings some benefit in terms of code size shrinking of
> vmlinux, for NR_CPUS=64, it reduce 78 bytes in total, for
> NR_CPUS=4096, it reduce 2 bytes in total. The details are shown in the
> table [1].
> 
> Performance test is done using the test script [2]. Running the test for
> 10000 times, the origin implementation of cpumask_any_but() use 19665287
> nanoseconds in total, the new version of it, which is a wrapper around
> cpumask_first_but(), uses 19545574 nanoseconds. The difference is 119713
> nanoseconds.
> 
> Co-developed-by: Yu-Chun Lin <eleanor15x@gmail.com>
> Signed-off-by: Yu-Chun Lin <eleanor15x@gmail.com>
> Signed-off-by: Kuan-Wei Chiu <visitorckw@gmail.com>

This looks like an invalid SoB chain.
In our private discussion, I did agree that you're free to build upon
my previous patch for further development. Since this patch is almost
identical to mine, I assume you intended to include me and Yu-Chun as
co-authors. If that's the case, you should also add a Co-developed-by:
tag for me. It might also be helpful to add a Link: tag pointing to my
original patch for better traceability.

https://docs.kernel.org/process/submitting-patches.html#when-to-use-acked-by-cc-and-co-developed-by

Regards,
Kuan-Wei

> Signed-off-by: I Hsin Cheng <richard120310@gmail.com>
> ---
> [1]:
> 
> For NR_CPUS=64:
> $ ./scripts/bloat-o-meter vmlinux_old vmlinux_new
> add/remove: 0/0 grow/shrink: 3/7 up/down: 46/-124 (-78)
> Function                                     old     new   delta
> irq_migrate_all_off_this_cpu                 716     745     +29
> try_to_unmap_one                            3380    3391     +11
> try_to_migrate_one                          2451    2457      +6
> uncore_event_cpu_offline                     343     342      -1
> calibrate_delay_is_known                     236     235      -1
> tsc_store_and_check_tsc_adjust               506     495     -11
> arch_tlbbatch_flush                          302     288     -14
> tmigr_cpu_offline                            406     382     -24
> perf_event_exit_cpu_context                  592     565     -27
> flush_tlb_mm_range                          1561    1515     -46
> Total: Before=23390770, After=23390692, chg -0.00%
> 
> For NR_CPUS=4096:
> $ ./scripts/bloat-o-meter vmlinux_old vmlinux_new
> add/remove: 0/0 grow/shrink: 7/3 up/down: 136/-138 (-2)
> Function                                     old     new   delta
> uncore_event_cpu_offline                     291     333     +42
> try_to_migrate_one                          2378    2413     +35
> flush_tlb_mm_range                          1476    1503     +27
> irq_migrate_all_off_this_cpu                 741     754     +13
> tmigr_cpu_offline                            353     362      +9
> calibrate_delay_is_known                     183     192      +9
> arch_tlbbatch_flush                          296     297      +1
> tsc_store_and_check_tsc_adjust               484     482      -2
> perf_event_exit_cpu_context                  546     528     -18
> try_to_unmap_one                            3560    3442    -118
> Total: Before=23448698, After=23448696, chg -0.00%
> 
> [2]:
> static int __init test_init(void)
> {
>     struct cpumask test_mask;
>     ktime_t start_time, end_time;
>     s64 elapsed_ns;
>     unsigned int result;
>     unsigned int random_cpu;
>     int i;
> 
>     cpumask_copy(&test_mask, cpu_online_mask);
> 
>     start_time = ktime_get();
> 
>     for (i = 0; i < 100000; i++) {
>         get_random_bytes(&random_cpu, sizeof(random_cpu));
>         random_cpu = random_cpu % nr_cpu_ids;
>         result = cpumask_any_but(&test_mask, random_cpu);
>     }
> 
>     end_time = ktime_get();
> 
>     elapsed_ns = ktime_to_ns(ktime_sub(end_time, start_time));
> 
> 	pr_info("Total time: %lld ns\n", elapsed_ns);
> 
>     return 0;
> }
> 
> The test is running in the form of kernel module.
> The test machine is running ubuntu 24.04 on x86_64 machine with kernel
> version of v6.14.0, CPU type is AMD Ryzen 7 5700X3D 8-Core Processor.
> 
> Best regards,
> I Hsin Cheng
> ---
>  include/linux/cpumask.h | 22 ++++++++++++++++------
>  1 file changed, 16 insertions(+), 6 deletions(-)
> 
> diff --git a/include/linux/cpumask.h b/include/linux/cpumask.h
> index f9a868384083..d91630a97d76 100644
> --- a/include/linux/cpumask.h
> +++ b/include/linux/cpumask.h
> @@ -408,22 +408,22 @@ unsigned int cpumask_next_wrap(int n, const struct cpumask *src)
>  	for_each_set_bit_from(cpu, cpumask_bits(mask), small_cpumask_bits)
>  
>  /**
> - * cpumask_any_but - return an arbitrary cpu in a cpumask, but not this one.
> + * cpumask_first_but - return the first cpu in a cpumask, but not this one.
>   * @mask: the cpumask to search
>   * @cpu: the cpu to ignore.
>   *
> - * Often used to find any cpu but smp_processor_id() in a mask.
> + * Often used to find the first cpu but smp_processor_id() in a mask.
>   * Return: >= nr_cpu_ids if no cpus set.
>   */
>  static __always_inline
> -unsigned int cpumask_any_but(const struct cpumask *mask, unsigned int cpu)
> +unsigned int cpumask_first_but(const struct cpumask *mask, unsigned int cpu)
>  {
>  	unsigned int i;
>  
>  	cpumask_check(cpu);
> -	for_each_cpu(i, mask)
> -		if (i != cpu)
> -			break;
> +	i = cpumask_first(mask);
> +	if (i == cpu)
> +		i = cpumask_next(i, mask);
>  	return i;
>  }
>  
> @@ -864,6 +864,16 @@ void cpumask_copy(struct cpumask *dstp, const struct cpumask *srcp)
>   */
>  #define cpumask_any(srcp) cpumask_first(srcp)
>  
> +/**
> + * cpumask_any_but - pick an arbitrary cpu from *srcp but not the given cpu
> + * @srcp: the input cpumask
> + * @cpu: the cpu to ignore
> + *
> + * Often used to find any cpu but smp_processor_id() in a mask.
> + * Return: >= nr_cpu_ids if no cpus set.
> + */
> +#define cpumask_any_but(srcp, cpu) cpumask_first_but(srcp, cpu)
> +
>  /**
>   * cpumask_any_and - pick an arbitrary cpu from *mask1 & *mask2
>   * @mask1: the first input cpumask
> -- 
> 2.43.0
> 

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [RFC PATCH 2/2] clocksource: Use cpumask_first_but() in clocksource_verify_choose_cpus()
  2025-06-13  5:02   ` Yury Norov
  2025-06-13  5:22     ` I Hsin Cheng
  2025-06-13  5:41     ` I Hsin Cheng
@ 2025-06-13  6:00     ` I Hsin Cheng
  2025-06-13 10:48     ` Thomas Gleixner
  3 siblings, 0 replies; 14+ messages in thread
From: I Hsin Cheng @ 2025-06-13  6:00 UTC (permalink / raw)
  To: Yury Norov
  Cc: linux, jstultz, tglx, sboyd, linux-kernel, eleanor15x, visitorckw,
	jserv, skhan, linux-kernel-mentees

On Fri, Jun 13, 2025 at 01:02:38AM -0400, Yury Norov wrote:
> I Hsin,
> 
> This exact change has already been submitted by me and is under review.
> 
> https://lore.kernel.org/all/20250604232550.40491-2-yury.norov@gmail.com/
> 
> I don't understand why are you undercutting my work, and moreover do it 
> for the second time.
> 
> For the first time you submitted something that duplicates my another
> patch from the exact same series. John Stultz has pointed that, so you're
> surely aware.
> 
> https://lore.kernel.org/all/CANDhNCoJ_MmpEfyuL+JWav+NUfQDH3dm196JSE-Mv3QrPUzi3g@mail.gmail.com/
> 
> Kernel development process implies that one makes sure that his work
> is unique and doesn't break someone else's development, at one's best
> knowledge.
> 
> What you're doing not only breaks this rule. You're in fact trying to
> get credit for the work that is done by someone else. This is the
> definition of fraud.
> 
> I cannot make sure that any other patches from you are unique and
> written by actually you. Therefore, I will not take your work anymore.
> 
> I encourage everyone else to be careful working with I Hsing Cheng
> and check his patches for uniqueness, at minimum.  
>

However, I have to defend myself while I'm sincerely sorry for causing
your trouble. I think the statement here is an excessive accusation, if
I mean to stole other's patch, why would I send the patch to the author?

I hope you can understand this, I was not careful enough and made this
trouble, I should've browse through your patch series thoroughly and
thus made this trouble, I'm sorry, but the accusation here is too over
for me.

Thanks,
I Hsin Cheng


> NAKed-by: Yury Norov <yury.norov@gmail.com>
> 
> Thanks,
> Yury
> 
> On Fri, Jun 13, 2025 at 11:34:47AM +0800, I Hsin Cheng wrote:
> > Utilize cpumask_first_but() helper instead of first using
> > cpumask_first() and then cpumask_next(). The logic is the same here,
> > using the new helper will make it more conscious.
> > 
> > Use bloat-o-meter to check the impact on code size, the result is the
> > same, does not have positive impact nor negative impact.
> > 
> > $ ./scripts/bloat-o-meter vmlinux_old vmlinux_new
> > add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0)
> > Function                                     old     new   delta
> > Total: Before=22590709, After=22590709, chg +0.00%
> > 
> > Signed-off-by: I Hsin Cheng <richard120310@gmail.com>
> > ---
> > Generally speaking, I think this is just a small tweak on the code,
> > making it more readable. However, no benefit in code size or performance
> > as the implementation behind the helper is in fact the same as the one
> > used here.
> > 
> > Maybe more tests should be done to ensure the change is solid, I hope to
> > seek some suggestions from everyone who has any ideas, or this is enough
> > then it's good.
> > 
> > Best regards,
> > I Hsin Cheng
> > ---
> >  kernel/time/clocksource.c | 4 +---
> >  1 file changed, 1 insertion(+), 3 deletions(-)
> > 
> > diff --git a/kernel/time/clocksource.c b/kernel/time/clocksource.c
> > index bb48498ebb5a..12ff0c048570 100644
> > --- a/kernel/time/clocksource.c
> > +++ b/kernel/time/clocksource.c
> > @@ -323,9 +323,7 @@ static void clocksource_verify_choose_cpus(void)
> >  		return;
> >  
> >  	/* Make sure to select at least one CPU other than the current CPU. */
> > -	cpu = cpumask_first(cpu_online_mask);
> > -	if (cpu == smp_processor_id())
> > -		cpu = cpumask_next(cpu, cpu_online_mask);
> > +	cpu = cpumask_first_but(cpu_online_mask, smp_processor_id());
> >  	if (WARN_ON_ONCE(cpu >= nr_cpu_ids))
> >  		return;
> >  	cpumask_set_cpu(cpu, &cpus_chosen);
> > -- 
> > 2.43.0

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [RFC PATCH 2/2] clocksource: Use cpumask_first_but() in clocksource_verify_choose_cpus()
  2025-06-13  5:02   ` Yury Norov
                       ` (2 preceding siblings ...)
  2025-06-13  6:00     ` I Hsin Cheng
@ 2025-06-13 10:48     ` Thomas Gleixner
  2025-06-13 11:37       ` I Hsin Cheng
                         ` (2 more replies)
  3 siblings, 3 replies; 14+ messages in thread
From: Thomas Gleixner @ 2025-06-13 10:48 UTC (permalink / raw)
  To: Yury Norov, I Hsin Cheng
  Cc: linux, jstultz, sboyd, linux-kernel, eleanor15x, visitorckw,
	jserv, skhan, linux-kernel-mentees

Yury!

On Fri, Jun 13 2025 at 01:02, Yury Norov wrote:
> This exact change has already been submitted by me and is under review.
>
> https://lore.kernel.org/all/20250604232550.40491-2-yury.norov@gmail.com/
>
> I don't understand why are you undercutting my work, and moreover do it 
> for the second time.
>
> For the first time you submitted something that duplicates my another
> patch from the exact same series. John Stultz has pointed that, so you're
> surely aware.
>
> https://lore.kernel.org/all/CANDhNCoJ_MmpEfyuL+JWav+NUfQDH3dm196JSE-Mv3QrPUzi3g@mail.gmail.com/
>
> Kernel development process implies that one makes sure that his work
> is unique and doesn't break someone else's development, at one's best
> knowledge.
>
> What you're doing not only breaks this rule. You're in fact trying to
> get credit for the work that is done by someone else. This is the
> definition of fraud.
>
> I cannot make sure that any other patches from you are unique and
> written by actually you. Therefore, I will not take your work anymore.
>
> I encourage everyone else to be careful working with I Hsing Cheng
> and check his patches for uniqueness, at minimum.  

There is absolutely no justification for accusing Hsin of fraud or other
nasty intentions.

It's sufficient to point him to your series and tell him that it's
already been dealt with.

I deal with redundant and conflicting patches every other day. That's part
of how open source development works and it's trivial enough to either
pick one of the patches or ask the involved parties to sort the
conflicts out.

Thanks,

        tglx

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [RFC PATCH 2/2] clocksource: Use cpumask_first_but() in clocksource_verify_choose_cpus()
  2025-06-13 10:48     ` Thomas Gleixner
@ 2025-06-13 11:37       ` I Hsin Cheng
  2025-06-13 16:29       ` Yury Norov
  2025-06-16 14:38       ` Shuah Khan
  2 siblings, 0 replies; 14+ messages in thread
From: I Hsin Cheng @ 2025-06-13 11:37 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: Yury Norov, linux, jstultz, sboyd, linux-kernel, eleanor15x,
	visitorckw, jserv, skhan, linux-kernel-mentees

On Fri, Jun 13, 2025 at 12:48:43PM +0200, Thomas Gleixner wrote:
> Yury!
> 
> On Fri, Jun 13 2025 at 01:02, Yury Norov wrote:
> > This exact change has already been submitted by me and is under review.
> >
> > https://lore.kernel.org/all/20250604232550.40491-2-yury.norov@gmail.com/
> >
> > I don't understand why are you undercutting my work, and moreover do it 
> > for the second time.
> >
> > For the first time you submitted something that duplicates my another
> > patch from the exact same series. John Stultz has pointed that, so you're
> > surely aware.
> >
> > https://lore.kernel.org/all/CANDhNCoJ_MmpEfyuL+JWav+NUfQDH3dm196JSE-Mv3QrPUzi3g@mail.gmail.com/
> >
> > Kernel development process implies that one makes sure that his work
> > is unique and doesn't break someone else's development, at one's best
> > knowledge.
> >
> > What you're doing not only breaks this rule. You're in fact trying to
> > get credit for the work that is done by someone else. This is the
> > definition of fraud.
> >
> > I cannot make sure that any other patches from you are unique and
> > written by actually you. Therefore, I will not take your work anymore.
> >
> > I encourage everyone else to be careful working with I Hsing Cheng
> > and check his patches for uniqueness, at minimum.  
> 
> There is absolutely no justification for accusing Hsin of fraud or other
> nasty intentions.
> 
> It's sufficient to point him to your series and tell him that it's
> already been dealt with.
> 
> I deal with redundant and conflicting patches every other day. That's part
> of how open source development works and it's trivial enough to either
> pick one of the patches or ask the involved parties to sort the
> conflicts out.
> 
> Thanks,
> 
>         tglx

Hello Thomas,

Thanks for your word, really appreciate it.
Though I can understand abit why Yury was annoyed for this patch, at the
patch [1] I sent earlier, it already collide with Yury's patch, he did
paste the link of his patch for me, but I only take a look at the patch
in the link, not the whole patch series.
And then I send this patch, again collide with his work, if it were me, I
might feel the same like alittle bit of offended.

I send this patch because after I send this patch [2] , I think of
Kuan-Wei's patch [3] months ago and see there might be a use case here,
so I ask Kuan-Wei whether I can pick up his work.

I admit I wasn't paying attention to detail enough when looking at other's
work, neither did I subscribe the mailing list cuz I don't want my mail
box to be exploded with mails that aren't sent to me.

My workflow for patches was making sure it works as expected, and then
use scripts to check patch format, get maintainers, and then send it. I
know there's always room for improvments or something I might've done
inappropriately, that's why I always send the first patch with RFC tag.

That's the whole story, I am sorry to Yury, but again I think the
accusation is too over, like I said earlier, if I mean to steal
someone's work, why would I send it directly to the author ?

Still, I respect Yury and his professions, months ago he gave me many
suggesetions and help in another patch.

That's why I send my patch [2] to him to asked him for some comments
even though he's not in the maintainers list of that file.
I would never want to offend someone I respect, I hope he can
understand.

[1]: https://lore.kernel.org/lkml/20250611104506.2270561-1-richard120310@gmail.com/
[2]: https://lore.kernel.org/lkml/20250609194611.690678-1-richard120310@gmail.com/
[3]: https://lore.kernel.org/lkml/20250117142658.297325-1-visitorckw@gmail.com/

Best regards,
I Hsin Cheng



^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [RFC PATCH 2/2] clocksource: Use cpumask_first_but() in clocksource_verify_choose_cpus()
  2025-06-13 10:48     ` Thomas Gleixner
  2025-06-13 11:37       ` I Hsin Cheng
@ 2025-06-13 16:29       ` Yury Norov
  2025-06-13 16:56         ` Thomas Gleixner
  2025-06-16 14:38       ` Shuah Khan
  2 siblings, 1 reply; 14+ messages in thread
From: Yury Norov @ 2025-06-13 16:29 UTC (permalink / raw)
  To: Thomas Gleixner
  Cc: I Hsin Cheng, linux, jstultz, sboyd, linux-kernel, eleanor15x,
	visitorckw, jserv, skhan, linux-kernel-mentees

On Fri, Jun 13, 2025 at 12:48:43PM +0200, Thomas Gleixner wrote:
> Yury!
> 
> On Fri, Jun 13 2025 at 01:02, Yury Norov wrote:
> > This exact change has already been submitted by me and is under review.
> >
> > https://lore.kernel.org/all/20250604232550.40491-2-yury.norov@gmail.com/
> >
> > I don't understand why are you undercutting my work, and moreover do it 
> > for the second time.
> >
> > For the first time you submitted something that duplicates my another
> > patch from the exact same series. John Stultz has pointed that, so you're
> > surely aware.
> >
> > https://lore.kernel.org/all/CANDhNCoJ_MmpEfyuL+JWav+NUfQDH3dm196JSE-Mv3QrPUzi3g@mail.gmail.com/
> >
> > Kernel development process implies that one makes sure that his work
> > is unique and doesn't break someone else's development, at one's best
> > knowledge.
> >
> > What you're doing not only breaks this rule. You're in fact trying to
> > get credit for the work that is done by someone else. This is the
> > definition of fraud.
> >
> > I cannot make sure that any other patches from you are unique and
> > written by actually you. Therefore, I will not take your work anymore.
> >
> > I encourage everyone else to be careful working with I Hsing Cheng
> > and check his patches for uniqueness, at minimum.  
> 
> There is absolutely no justification for accusing Hsin of fraud or other
> nasty intentions.

No, there is. It looks like a pure plagiarism - a sort of fraud.

You see, in the other email in this thread Kuan-Wei Chiu complains
about the lack of credit, as well.
 
> It's sufficient to point him to your series and tell him that it's
> already been dealt with.

He'd been pointed at least once. Obviously, it's not sufficient in
this case.

> I deal with redundant and conflicting patches every other day. That's part
> of how open source development works and it's trivial enough to either
> pick one of the patches or ask the involved parties to sort the
> conflicts out.

It's not about conflicts. I know how conflicts look and how to manage
them. Check this example from the last merge window:

        791a9b25ce2e6ecbe404ee32eed8a96a17e52896

I work on kernel for over 15 years, and contribute regularly for at least
a decade, and such thing happens to me for the first time. If it's indeed
a normal workflow, can you please share a couple recent examples where
people submit someone else's patchsets in whole with different commit
messages and with absolutely no credit, despite being warned? I'll then
consider to adjust my tolerance level to such things.

Nevertheless.

At this point it looks more like a lack of professionalism rather than
an evil will, and I hope he'll do better next time.

This doesn't mean that I revoke my NAK, or willing to give him any
credit for this work. But I will review and take his patches in case
he'll send something valuable to me; with reasonable precautions.

Thanks,
Yury

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [RFC PATCH 2/2] clocksource: Use cpumask_first_but() in clocksource_verify_choose_cpus()
  2025-06-13 16:29       ` Yury Norov
@ 2025-06-13 16:56         ` Thomas Gleixner
  0 siblings, 0 replies; 14+ messages in thread
From: Thomas Gleixner @ 2025-06-13 16:56 UTC (permalink / raw)
  To: Yury Norov
  Cc: I Hsin Cheng, linux, jstultz, sboyd, linux-kernel, eleanor15x,
	visitorckw, jserv, skhan, linux-kernel-mentees

On Fri, Jun 13 2025 at 12:29, Yury Norov wrote:
> On Fri, Jun 13, 2025 at 12:48:43PM +0200, Thomas Gleixner wrote:
> At this point it looks more like a lack of professionalism rather than
> an evil will, and I hope he'll do better next time.

Indeed.

> This doesn't mean that I revoke my NAK, or willing to give him any
> credit for this work. But I will review and take his patches in case
> he'll send something valuable to me; with reasonable precautions.

Fair enough.

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [RFC PATCH 2/2] clocksource: Use cpumask_first_but() in clocksource_verify_choose_cpus()
  2025-06-13  5:22     ` I Hsin Cheng
@ 2025-06-16 14:34       ` Shuah Khan
  0 siblings, 0 replies; 14+ messages in thread
From: Shuah Khan @ 2025-06-16 14:34 UTC (permalink / raw)
  To: I Hsin Cheng, Yury Norov
  Cc: linux, jstultz, tglx, sboyd, linux-kernel, eleanor15x, visitorckw,
	jserv, linux-kernel-mentees, Shuah Khan

On 6/12/25 23:22, I Hsin Cheng wrote:
> On Fri, Jun 13, 2025 at 01:02:38AM -0400, Yury Norov wrote:
>> I Hsin,
>>
>> This exact change has already been submitted by me and is under review.
>>
>> https://lore.kernel.org/all/20250604232550.40491-2-yury.norov@gmail.com/
>>
>> I don't understand why are you undercutting my work, and moreover do it
>> for the second time.
>>
>> For the first time you submitted something that duplicates my another
>> patch from the exact same series. John Stultz has pointed that, so you're
>> surely aware.
>>
>> https://lore.kernel.org/all/CANDhNCoJ_MmpEfyuL+JWav+NUfQDH3dm196JSE-Mv3QrPUzi3g@mail.gmail.com/
>>
>> Kernel development process implies that one makes sure that his work
>> is unique and doesn't break someone else's development, at one's best
>> knowledge.
>>
>> What you're doing not only breaks this rule. You're in fact trying to
>> get credit for the work that is done by someone else. This is the
>> definition of fraud.
>>
>> I cannot make sure that any other patches from you are unique and
>> written by actually you. Therefore, I will not take your work anymore.
>>
>> I encourage everyone else to be careful working with I Hsing Cheng
>> and check his patches for uniqueness, at minimum.
>>
>> NAKed-by: Yury Norov <yury.norov@gmail.com>
>>
>> Thanks,
>> Yury
>>
> 
> Hello Yury,
> 
> Sorry to make troubles, I didn't mean to do this, I wasn't aware that
> you've send the same work and nor do I mean to interrupt your work. I
> didn't have the habit to check others patches regularly, I'm sorry for
> that.
> 
> I just saw Kuan-Wei's patch from months ago and I asked him whether I
> can continue that work, and he agrees, so I try to do something from
> there.
> 
> Again sorry for causing troubles, I'll make sure to look for others
> patches first before submitting them.
> 
> Sincerely sorry for this.
> 
> Thanks,
> I Hsin Cheng
> 
>> On Fri, Jun 13, 2025 at 11:34:47AM +0800, I Hsin Cheng wrote:
>>> Utilize cpumask_first_but() helper instead of first using
>>> cpumask_first() and then cpumask_next(). The logic is the same here,
>>> using the new helper will make it more conscious.
>>>
>>> Use bloat-o-meter to check the impact on code size, the result is the
>>> same, does not have positive impact nor negative impact.
>>>
>>> $ ./scripts/bloat-o-meter vmlinux_old vmlinux_new
>>> add/remove: 0/0 grow/shrink: 0/0 up/down: 0/0 (0)
>>> Function                                     old     new   delta
>>> Total: Before=22590709, After=22590709, chg +0.00%
>>>
>>> Signed-off-by: I Hsin Cheng <richard120310@gmail.com>
>>> ---
>>> Generally speaking, I think this is just a small tweak on the code,
>>> making it more readable. However, no benefit in code size or performance
>>> as the implementation behind the helper is in fact the same as the one
>>> used here.
>>>
>>> Maybe more tests should be done to ensure the change is solid, I hope to
>>> seek some suggestions from everyone who has any ideas, or this is enough
>>> then it's good.
>>>

Thank you for explaining what transpired and clearing the misunderstanding.
It can be difficult to figure if there is a duplicate patch unless you
are closely watching the mailing lists - it is very hard to keep up.

Don't be discouraged with this experience. Continue to contribute.

thanks,
-- Shuah

^ permalink raw reply	[flat|nested] 14+ messages in thread

* Re: [RFC PATCH 2/2] clocksource: Use cpumask_first_but() in clocksource_verify_choose_cpus()
  2025-06-13 10:48     ` Thomas Gleixner
  2025-06-13 11:37       ` I Hsin Cheng
  2025-06-13 16:29       ` Yury Norov
@ 2025-06-16 14:38       ` Shuah Khan
  2 siblings, 0 replies; 14+ messages in thread
From: Shuah Khan @ 2025-06-16 14:38 UTC (permalink / raw)
  To: Thomas Gleixner, Yury Norov, I Hsin Cheng
  Cc: linux, jstultz, sboyd, linux-kernel, eleanor15x, visitorckw,
	jserv, linux-kernel-mentees, Shuah Khan

On 6/13/25 04:48, Thomas Gleixner wrote:
> Yury!
> 
> On Fri, Jun 13 2025 at 01:02, Yury Norov wrote:
>> This exact change has already been submitted by me and is under review.
>>
>> https://lore.kernel.org/all/20250604232550.40491-2-yury.norov@gmail.com/
>>
>> I don't understand why are you undercutting my work, and moreover do it
>> for the second time.
>>
>> For the first time you submitted something that duplicates my another
>> patch from the exact same series. John Stultz has pointed that, so you're
>> surely aware.
>>
>> https://lore.kernel.org/all/CANDhNCoJ_MmpEfyuL+JWav+NUfQDH3dm196JSE-Mv3QrPUzi3g@mail.gmail.com/
>>
>> Kernel development process implies that one makes sure that his work
>> is unique and doesn't break someone else's development, at one's best
>> knowledge.
>>
>> What you're doing not only breaks this rule. You're in fact trying to
>> get credit for the work that is done by someone else. This is the
>> definition of fraud.
>>
>> I cannot make sure that any other patches from you are unique and
>> written by actually you. Therefore, I will not take your work anymore.
>>
>> I encourage everyone else to be careful working with I Hsing Cheng
>> and check his patches for uniqueness, at minimum.
> 
> There is absolutely no justification for accusing Hsin of fraud or other
> nasty intentions.
> 
> It's sufficient to point him to your series and tell him that it's
> already been dealt with.

Thank you Thomas.

I Hsin is enrolled in kernel mentorship program and is new to the
kernel community. Pleas give them the benefit of the doubt. It can
be overwhelming when you just start sending patches. It can be
difficult to figure out if there is duplicate work happening.

Duplicate patches happen during kernel workflow. Most of us have done
that at least once.

thanks,
-- Shuah

^ permalink raw reply	[flat|nested] 14+ messages in thread

end of thread, other threads:[~2025-06-16 14:38 UTC | newest]

Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-06-13  3:34 [RFC PATCH 0/2] Introduce cpumask_first_but() and use cases I Hsin Cheng
2025-06-13  3:34 ` [RFC PATCH 1/2] cpumask: Introduce cpumask_first_but() I Hsin Cheng
2025-06-13  5:55   ` Kuan-Wei Chiu
2025-06-13  3:34 ` [RFC PATCH 2/2] clocksource: Use cpumask_first_but() in clocksource_verify_choose_cpus() I Hsin Cheng
2025-06-13  5:02   ` Yury Norov
2025-06-13  5:22     ` I Hsin Cheng
2025-06-16 14:34       ` Shuah Khan
2025-06-13  5:41     ` I Hsin Cheng
2025-06-13  6:00     ` I Hsin Cheng
2025-06-13 10:48     ` Thomas Gleixner
2025-06-13 11:37       ` I Hsin Cheng
2025-06-13 16:29       ` Yury Norov
2025-06-13 16:56         ` Thomas Gleixner
2025-06-16 14:38       ` Shuah Khan

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox