Hi all,

Based on Michal's suggestion, the following changes were made:
1. Changed Union-Find to union-find in all places except the title.
2. Optimized the logic of the uf_union function.
3. Modified places where csa[i]->node.parent was used directly.

To Longman,
Regarding the modifications for supporting cpuset merging in both cgroup
v1 and v2, do you mean that you will continue to complete them after my
patch is merged?

Kindly review.

Xavier (2):
  Union-Find: add a new module in kernel library
  cpuset: use Union-Find to optimize the merging of cpumasks

 Documentation/core-api/union_find.rst         | 102 ++++++++++++++++
 .../zh_CN/core-api/union_find.rst             |  87 +++++++++++++
 MAINTAINERS                                   |   9 ++
 include/linux/union_find.h                    |  41 +++++++
 kernel/cgroup/cpuset.c                        | 114 +++++++-----------
 lib/Makefile                                  |   2 +-
 lib/union_find.c                              |  49 ++++++++
 7 files changed, 333 insertions(+), 71 deletions(-)
 create mode 100644 Documentation/core-api/union_find.rst
 create mode 100644 Documentation/translations/zh_CN/core-api/union_find.rst
 create mode 100644 include/linux/union_find.h
 create mode 100644 lib/union_find.c

-- 
2.45.0

On 7/4/24 02:24, Xavier wrote:
> Hi all,
>
> Based on Michal's suggestion, the following changes were made:
> 1. Changed Union-Find to union-find in all places except the title.
> 2. Optimized the logic of the uf_union function.
> 3. Modified places where csa[i]->node.parent was used directly.
>
> To Longman,
> Regarding the modifications for supporting cpuset merging in both cgroup
> v1 and v2, do you mean that you will continue to complete them after my
> patch is merged?
Yes.
>
> Kindly review.
>
> Xavier (2):
>    Union-Find: add a new module in kernel library
>    cpuset: use Union-Find to optimize the merging of cpumasks
>
>   Documentation/core-api/union_find.rst         | 102 ++++++++++++++++
>   .../zh_CN/core-api/union_find.rst             |  87 +++++++++++++
>   MAINTAINERS                                   |   9 ++
>   include/linux/union_find.h                    |  41 +++++++
>   kernel/cgroup/cpuset.c                        | 114 +++++++-----------
>   lib/Makefile                                  |   2 +-
>   lib/union_find.c                              |  49 ++++++++
>   7 files changed, 333 insertions(+), 71 deletions(-)
>   create mode 100644 Documentation/core-api/union_find.rst
>   create mode 100644 Documentation/translations/zh_CN/core-api/union_find.rst
>   create mode 100644 include/linux/union_find.h
>   create mode 100644 lib/union_find.c
>
The patch series looks good to me. However, it is a still major change 
in the domain generation algorithm and it is too late for v6.11. I would 
also like it to spend more time in linux-next as I don't have a good set 
of cgroup v1 test. I will support merging this for v6.12.

Acked-by: Waiman Long <longman@redhat.com>

On Sun, Jul 07, 2024 at 09:59:55PM -0400, Waiman Long wrote:
> The patch series looks good to me. However, it is a still major change in
> the domain generation algorithm and it is too late for v6.11. I would also
> like it to spend more time in linux-next as I don't have a good set of
> cgroup v1 test. I will support merging this for v6.12.
> 
> Acked-by: Waiman Long <longman@redhat.com>

Xavier, as we're pretty close to the merge window, I think it'd be best to
do this in the next merge window as Waiman said. Can you please ping me once
v6.11-rc1 is cut? I'll apply the two patches on cgroup/for-6.12.

Thanks.

-- 
tejun

Hi Tejun,

I saw on kernel.org that v6.11-rc1 has been released. It might be time to start merging
this patch. 

By the way,  I have submitted an optimization patch for RT group scheduling, but after
two rounds of communication, I haven't received any further responses. Could you
provide me with some advice?

https://lore.kernel.org/all/20240627172156.235421-1-xavier_qy@163.com/

Thanks.


At 2024-07-09 02:38:33, "Tejun Heo" <tj@kernel.org> wrote:
>On Sun, Jul 07, 2024 at 09:59:55PM -0400, Waiman Long wrote:
>> The patch series looks good to me. However, it is a still major change in
>> the domain generation algorithm and it is too late for v6.11. I would also
>> like it to spend more time in linux-next as I don't have a good set of
>> cgroup v1 test. I will support merging this for v6.12.
>> 
>> Acked-by: Waiman Long <longman@redhat.com>
>
>Xavier, as we're pretty close to the merge window, I think it'd be best to
>do this in the next merge window as Waiman said. Can you please ping me once
>v6.11-rc1 is cut? I'll apply the two patches on cgroup/for-6.12.
>



--
Best Regards,
Xavier

Hello,

On Mon, Jul 29, 2024 at 10:44:08AM +0800, Xavier wrote:
> I saw on kernel.org that v6.11-rc1 has been released. It might be time to start merging
> this patch. 

Merged two patches.

> By the way,  I have submitted an optimization patch for RT group scheduling, but after
> two rounds of communication, I haven't received any further responses. Could you
> provide me with some advice?
> 
> https://lore.kernel.org/all/20240627172156.235421-1-xavier_qy@163.com/

I'm not sure I have a useful advice other than just pinging again.

Thanks.

-- 
tejun

Hi tejun,


Sure, that works. We can wait to merge it into the cgroup/for-6.12 branch. I will ping you once v6.11-rc1 is cut.
Thank you.


--
Best Regards,
Xavier




At 2024-07-09 02:38:33, "Tejun Heo" <tj@kernel.org> wrote:
>On Sun, Jul 07, 2024 at 09:59:55PM -0400, Waiman Long wrote:
>> The patch series looks good to me. However, it is a still major change in
>> the domain generation algorithm and it is too late for v6.11. I would also
>> like it to spend more time in linux-next as I don't have a good set of
>> cgroup v1 test. I will support merging this for v6.12.
>> 
>> Acked-by: Waiman Long <longman@redhat.com>
>
>Xavier, as we're pretty close to the merge window, I think it'd be best to
>do this in the next merge window as Waiman said. Can you please ping me once
>v6.11-rc1 is cut? I'll apply the two patches on cgroup/for-6.12.
>
>Thanks.
>
>-- 
>tejun