On Wed, 23 Oct 2024 09:20:04 -0700 Anjali Kulkarni wrote:
> Add a new type PROC_CN_MCAST_NOTIFY to proc connector API, which allows a
> thread to notify the kernel that is going to exit with a non-zero exit
> code and specify the exit code in it. When thread exits in the kernel,
> it will send this
unit.o
CFLAGS_stackinit_kunit.o += $(call cc-disable-warning, switch-unreachable)
diff --git a/lib/cn_hash_test.c b/lib/cn_hash_test.c
new file mode 100644
index 00000000..efaf727d9b2a
--- /dev/null
+++ b/lib/cn_hash_test.c
@@ -0,0 +1,169 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * KUnit test
Test to check if setting PROC_CN_MCAST_NOTIFY in proc connector API, allows
a thread's non-zero exit status to be returned to proc_filter.
The threads.c program creates 2 child threads. 1st thread handles signal
SIGSEGV, and 2nd thread needs to indicate some error condition (value 1)
t
Recently we committed a fix to allow processes to receive notifications for
non-zero exits via the process connector module. Commit is a4c9a56e6a2c.
However, for threads, when it does a pthread_exit(&exit_status) call, the
kernel is not aware of the exit status with which pthread_exit is ca
.
Exiting thread can call this either when it wants to call pthread_exit()
with non-zero value or from signal handler.
Add a new file cn_hash.c which implements a hash table storing the exit
codes of abnormally exiting threads, received by the system call above.
The key used for the hash table is
> On Oct 23, 2024, at 8:05 AM, Stanislav Fomichev wrote:
>
> On 10/23, Anjali Kulkarni wrote:
>> […snip…]
>>
>>
>> Yes, make sure all required options are picked up by
>> "./tools/testing/kunit/kunit.py run" instead of manually adding options
>> and doing modprobe.
>
On 10/23, Anjali Kulkarni wrote:
> […snip…]
>
>
> Yes, make sure all required options are picked up by
> "./tools/testing/kunit/kunit.py run" instead of manually adding options
> and doing modprobe.
> >>>
> >>> The environment issues are resolved and I am able to run kunit.py
[…snip…]
Yes, make sure all required options are picked up by
"./tools/testing/kunit/kunit.py run" instead of manually adding options
and doing modprobe.
>>>
>>> The environment issues are resolved and I am able to run kunit.py, but my
>>> tests
>>> are not invoked without g
> On Oct 22, 2024, at 4:50 PM, Stanislav Fomichev wrote:
>
> On 10/22, Anjali Kulkarni wrote:
>>
>>
>>> On Oct 17, 2024, at 5:55 PM, Stanislav Fomichev
>>> wrote:
>>>
>>> On 10/18, Anjali Kulkarni wrote:
> On Oct 17, 2024, at 5:13 PM, Stanislav Fomichev
> wrote:
>
On 10/22, Anjali Kulkarni wrote:
>
>
> > On Oct 17, 2024, at 5:55 PM, Stanislav Fomichev
> > wrote:
> >
> > On 10/18, Anjali Kulkarni wrote:
> >>
> >>
> >>> On Oct 17, 2024, at 5:13 PM, Stanislav Fomichev
> >>> wrote:
> >>>
> >>> On 10/17, Anjali Kulkarni wrote:
> Kunit tests to test
> On Oct 17, 2024, at 5:55 PM, Stanislav Fomichev wrote:
>
> On 10/18, Anjali Kulkarni wrote:
>>
>>
>>> On Oct 17, 2024, at 5:13 PM, Stanislav Fomichev
>>> wrote:
>>>
>>> On 10/17, Anjali Kulkarni wrote:
Kunit tests to test hash table add, delete, duplicate add and delete.
Add fo
Hi Anjali,
kernel test robot noticed the following build errors:
[auto build test ERROR on net-next/main]
url:
https://github.com/intel-lab-lkp/linux/commits/Anjali-Kulkarni/connector-cn_proc-Add-hash-table-for-threads/20241018-021755
base: net-next/main
patch link:
https
Hi Anjali,
kernel test robot noticed the following build errors:
[auto build test ERROR on net-next/main]
url:
https://github.com/intel-lab-lkp/linux/commits/Anjali-Kulkarni/connector-cn_proc-Add-hash-table-for-threads/20241018-021755
base: net-next/main
patch link:
https
t;>
>> The threads.c program creates 2 child threads. 1st thread handles signal
>> SIGSEGV, and 2nd thread needs to indicate some error condition (value 1)
>> to the kernel, instead of using pthread_exit() with 1.
>>
>> In both cases, child sends notify_netlink_
.
>>
>> However, for threads, when it does a pthread_exit(&exit_status) call, the
>> kernel is not aware of the exit status with which pthread_exit is called.
>> It is sent by child thread to the parent process, if it is waiting in
>> pthread_join(). Hence,
On 10/18, Anjali Kulkarni wrote:
>
>
> > On Oct 17, 2024, at 5:55 PM, Stanislav Fomichev
> > wrote:
> >
> > On 10/18, Anjali Kulkarni wrote:
> >>
> >>
> >>> On Oct 17, 2024, at 5:13 PM, Stanislav Fomichev
> >>> wrote:
> >>>
> >>> On 10/17, Anjali Kulkarni wrote:
> Kunit tests to test
On Thu, Oct 17, 2024 at 11:14:36AM -0700, Anjali Kulkarni wrote:
> Test to check if setting PROC_CN_MCAST_NOTIFY in proc connector API, allows
> a thread's non-zero exit status to be returned to proc_filter.
>
> The threads.c program creates 2 child threads. 1st thread handles
On Thu, Oct 17, 2024 at 11:14:33AM -0700, Anjali Kulkarni wrote:
> Recently we committed a fix to allow processes to receive notifications for
> non-zero exits via the process connector module. Commit is a4c9a56e6a2c.
>
> However, for threads, when it does a pthread_exit(&exit_s
> On Oct 17, 2024, at 5:55 PM, Stanislav Fomichev wrote:
>
> On 10/18, Anjali Kulkarni wrote:
>>
>>
>>> On Oct 17, 2024, at 5:13 PM, Stanislav Fomichev
>>> wrote:
>>>
>>> On 10/17, Anjali Kulkarni wrote:
Kunit tests to test hash table add, delete, duplicate add and delete.
Add fo
On 10/18, Anjali Kulkarni wrote:
>
>
> > On Oct 17, 2024, at 5:13 PM, Stanislav Fomichev
> > wrote:
> >
> > On 10/17, Anjali Kulkarni wrote:
> >> Kunit tests to test hash table add, delete, duplicate add and delete.
> >> Add following configs and compile kernel code:
> >>
> >> CONFIG_CONNECTO
> On Oct 17, 2024, at 5:13 PM, Stanislav Fomichev wrote:
>
> On 10/17, Anjali Kulkarni wrote:
>> Kunit tests to test hash table add, delete, duplicate add and delete.
>> Add following configs and compile kernel code:
>>
>> CONFIG_CONNECTOR=y
>> CONFIG_PROC_EVENTS=y
>> CONFIG_NET=y
>> CONFIG_KU
On 10/17, Anjali Kulkarni wrote:
> Kunit tests to test hash table add, delete, duplicate add and delete.
> Add following configs and compile kernel code:
>
> CONFIG_CONNECTOR=y
> CONFIG_PROC_EVENTS=y
> CONFIG_NET=y
> CONFIG_KUNIT=m
> CONFIG_CN_HASH_KUNIT_TEST=m
>
> To run kunit tests:
> sudo modp
-warning,
tautological-constant-out-of-range-compare)
obj-$(CONFIG_OVERFLOW_KUNIT_TEST) += overflow_kunit.o
CFLAGS_stackinit_kunit.o += $(call cc-disable-warning, switch-unreachable)
diff --git a/lib/cn_hash_test.c b/lib/cn_hash_test.c
new file mode 100644
index 0000..f90989343468
--- /
.
Exiting thread can call this either when it wants to call pthread_exit()
with non-zero value or from signal handler.
Add a new file cn_hash.c which implements a hash table storing the exit
codes of abnormally exiting threads, received by the system call above.
The key used for the hash table is
Test to check if setting PROC_CN_MCAST_NOTIFY in proc connector API, allows
a thread's non-zero exit status to be returned to proc_filter.
The threads.c program creates 2 child threads. 1st thread handles signal
SIGSEGV, and 2nd thread needs to indicate some error condition (value 1)
t
Recently we committed a fix to allow processes to receive notifications for
non-zero exits via the process connector module. Commit is a4c9a56e6a2c.
However, for threads, when it does a pthread_exit(&exit_status) call, the
kernel is not aware of the exit status with which pthread_exit is ca
>> Add a new file cn_hash.c which implements a hash table storing the exit
>> codes of abnormally exiting threads, received by the system call above.
>> The key used for the hash table is the pid of the thread, so when the
>> thread actually exits, we lookup it's pid in
de as a proc filter notification to any
> listening process.
> Exiting thread can call this either when it wants to call pthread_exit()
> with non-zero value or from signal handler.
>
> Add a new file cn_hash.c which implements a hash table storing the exit
> codes of abnormally ex
de as a proc filter notification to any
> listening process.
> Exiting thread can call this either when it wants to call pthread_exit()
> with non-zero value or from signal handler.
>
> Add a new file cn_hash.c which implements a hash table storing the exit
> codes of abnormally ex
Test to check if setting PROC_CN_MCAST_NOTIFY in proc connector API, allows
a thread's non-zero exit status to be returned to proc_filter.
The threads.c program creates 2 child threads. 1st thread handles signal
SIGSEGV, and 2nd thread needs to indicate some error condition (value 1)
t
.
Exiting thread can call this either when it wants to call pthread_exit()
with non-zero value or from signal handler.
Add a new file cn_hash.c which implements a hash table storing the exit
codes of abnormally exiting threads, received by the system call above.
The key used for the hash table is
ll cc-disable-warning,
tautological-constant-out-of-range-compare)
obj-$(CONFIG_OVERFLOW_KUNIT_TEST) += overflow_kunit.o
CFLAGS_stackinit_kunit.o += $(call cc-disable-warning, switch-unreachable)
diff --git a/lib/cn_hash_test.c b/lib/cn_hash_test.c
new file mode 100644
index 0000..f90
Recently we committed a fix to allow processes to receive notifications for
non-zero exits via the process connector module. Commit is a4c9a56e6a2c.
However, for threads, when it does a pthread_exit(&exit_status) call, the
kernel is not aware of the exit status with which pthread_exit is ca
ll cc-disable-warning,
tautological-constant-out-of-range-compare)
obj-$(CONFIG_OVERFLOW_KUNIT_TEST) += overflow_kunit.o
CFLAGS_stackinit_kunit.o += $(call cc-disable-warning, switch-unreachable)
diff --git a/lib/cn_hash_test.c b/lib/cn_hash_test.c
new file mode 100644
index 0000..78c
Recently we committed a fix to allow processes to receive notifications for
non-zero exits via the process connector module. Commit is a4c9a56e6a2c.
However, for threads, when it does a pthread_exit(&exit_status) call, the
kernel is not aware of the exit status with which pthread_exit is ca
Test to check if setting PROC_CN_MCAST_NOTIFY in proc connector API, allows
a thread's non-zero exit status to be returned to proc_filter.
The threads.c program creates 2 child threads. 1st thread handles signal
SIGSEGV, and 2nd thread needs to indicate some error condition (value 1)
t
.
Exiting thread can call this either when it wants to call pthread_exit()
with non-zero value or from signal handler.
Add a new file cn_hash.c which implements a hash table storing the exit
codes of abnormally exiting threads, received by the system call above.
The key used for the hash table is
N_MCAST_NOTIFY in proc connector API, allows
>>>> a thread's non-zero exit status to be returned to proc_filter.
>>>>
>>>> The threads.c program creates 2 child threads. 1st thread handles signal
>>>> SIGSEGV, and 2nd thread needs to indicate so
[..snip..]
>> +void cn_hash_free_elem(struct uexit_pid_hnode *elem);
>> +int cn_hash_add_elem(struct cn_hash_dev *hdev, __u32 uexit_code, pid_t pid);
>> +int cn_hash_del_elem(struct cn_hash_dev *hdev, pid_t pid);
>> +__u32 cn_hash_del_get_exval(struct cn_hash_dev *hdev, pid_t pid);
>> +__u32 cn_
-zero exit status to be returned to proc_filter.
> >>
> >> The threads.c program creates 2 child threads. 1st thread handles signal
> >> SIGSEGV, and 2nd thread needs to indicate some error condition (value 1)
> >> to the kernel, instead of using pthread_exit() with 1.
&g
* Anjali Kulkarni [241015 17:11]:
...
> >> +MODULE_DESCRIPTION("KUnit test for the connector threads hashtable code");
> >> +MODULE_LICENSE("GPL");
> >> diff --git a/lib/cn_hash_test.h b/lib/cn_hash_test.h
> >> new file mode 100644
> On Oct 15, 2024, at 12:27 PM, Liam Howlett wrote:
>
> * Anjali Kulkarni [241015 13:30]:
>> Test to check if setting PROC_CN_MCAST_NOTIFY in proc connector API, allows
>> a thread's non-zero exit status to be returned to proc_filter.
>>
>> The threads.
nnector/cn_hash.c.
>> + CONFIG_CONNECTOR=y, CONFIG_PROC_EVENTS=y as well as CONFIG_NET=y
>> + needs to be enabled along with CONFIG_CN_HASH_KUNIT_TEST=m and
>> + CONFIG_KUNIT=m in .config file to compile and then test as a kernel
>> + module with "modprobe c
* Anjali Kulkarni [241015 13:30]:
> Test to check if setting PROC_CN_MCAST_NOTIFY in proc connector API, allows
> a thread's non-zero exit status to be returned to proc_filter.
>
> The threads.c program creates 2 child threads. 1st thread handles signal
> SIGSEGV, and
/Makefile
> @@ -379,6 +379,7 @@ obj-$(CONFIG_CMDLINE_KUNIT_TEST) += cmdline_kunit.o
> obj-$(CONFIG_SLUB_KUNIT_TEST) += slub_kunit.o
> obj-$(CONFIG_MEMCPY_KUNIT_TEST) += memcpy_kunit.o
> obj-$(CONFIG_IS_SIGNED_TYPE_KUNIT_TEST) += is_signed_type_kunit.o
> +obj-$(CONFIG_CN_HASH_KUNIT_
rom signal handler.
>>
>> Add a new file cn_hash.c which implements a hash table storing the exit
>> codes of abnormally exiting threads, received by the system call above.
>> The key used for the hash table is the pid of the thread, so when the
>> thread actually
de as a proc filter notification to any
> listening process.
> Exiting thread can call this either when it wants to call pthread_exit()
> with non-zero value or from signal handler.
>
> Add a new file cn_hash.c which implements a hash table storing the exit
> codes of abnormally ex
Test to check if setting PROC_CN_MCAST_NOTIFY in proc connector API, allows
a thread's non-zero exit status to be returned to proc_filter.
The threads.c program creates 2 child threads. 1st thread handles signal
SIGSEGV, and 2nd thread needs to indicate some error condition (value 1)
t
t.c
new file mode 100644
index ..78c39c0a0997
--- /dev/null
+++ b/lib/cn_hash_test.c
@@ -0,0 +1,167 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * KUnit test for the connector threads hashtable code.
+ *
+ * Copyright (c) 2024 Oracle and/or its affiliates.
+ * Author: Anjali K
.
Exiting thread can call this either when it wants to call pthread_exit()
with non-zero value or from signal handler.
Add a new file cn_hash.c which implements a hash table storing the exit
codes of abnormally exiting threads, received by the system call above.
The key used for the hash table is
Recently we committed a fix to allow processes to receive notifications for
non-zero exits via the process connector module. Commit is a4c9a56e6a2c.
However, for threads, when it does a pthread_exit(&exit_status) call, the
kernel is not aware of the exit status with which pthread_exit is ca
On 10/15/24, 9:48 AM, "Jakub Kicinski" mailto:k...@kernel.org>> wrote:
On Tue, 15 Oct 2024 16:22:24 + Anjali Kulkarni wrote:
> Thank you! However, looking at the MAINTAINERS file,
> drivers/connector/ is listed under NETWORKING DRIVERS.
> Hence sending on net-next is the most appropriate p
On Tue, 15 Oct 2024 16:22:24 + Anjali Kulkarni wrote:
> Thank you! However, looking at the MAINTAINERS file,
> drivers/connector/ is listed under NETWORKING DRIVERS.
> Hence sending on net-next is the most appropriate place?
Hm. It was done relatively recently in
commit 46cf789b68b25744be3
On 10/15/24, 9:02 AM, "Jakub Kicinski" mailto:k...@kernel.org>> wrote:
On Sun, 13 Oct 2024 10:06:14 -0700 Anjali Kulkarni wrote:
> However, for threads, when it does a pthread_exit(&exit_status) call, the
> kernel is not aware of the exit status with which pthread_ex
On Sun, 13 Oct 2024 10:06:14 -0700 Anjali Kulkarni wrote:
> However, for threads, when it does a pthread_exit(&exit_status) call, the
> kernel is not aware of the exit status with which pthread_exit is called.
> It is sent by child thread to the parent process, if it is waiting in
&
On 10/14/24, 1:28 AM, "Peter Zijlstra" mailto:pet...@infradead.org>> wrote:
On Sun, Oct 13, 2024 at 10:06:15AM -0700, Anjali Kulkarni wrote:
> + if (unlikely(task->flags & PF_EXIT_NOTIFY)) {
> + task_lock(task);
> + task->flags &= ~PF_EXIT_NOTIFY;
> + task_unlock(task);
> +
> @@ -413,6 +44
On Sun, Oct 13, 2024 at 10:06:15AM -0700, Anjali Kulkarni wrote:
> + if (unlikely(task->flags & PF_EXIT_NOTIFY)) {
> + task_lock(task);
> + task->flags &= ~PF_EXIT_NOTIFY;
> + task_unlock(task);
> +
> @@ -413,6 +440,15 @@ static void cn_proc_mcast_ctl(struc
t.c
new file mode 100644
index ..78c39c0a0997
--- /dev/null
+++ b/lib/cn_hash_test.c
@@ -0,0 +1,167 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * KUnit test for the connector threads hashtable code.
+ *
+ * Copyright (c) 2024 Oracle and/or its affiliates.
+ * Author: Anjali K
.
Exiting thread can call this either when it wants to call pthread_exit()
with non-zero value or from signal handler.
Add a new file cn_hash.c which implements a hash table storing the exit
codes of abnormally exiting threads, received by the system call above.
The key used for the hash table is
Test to check if setting PROC_CN_MCAST_NOTIFY in proc connector API, allows
a thread's non-zero exit status to be returned to proc_filter.
The threads.c program creates 2 child threads. 1st thread handles signal
SIGSEGV, and 2nd thread needs to indicate some error condition (value 1)
t
Recently we committed a fix to allow processes to receive notifications for
non-zero exits via the process connector module. Commit is a4c9a56e6a2c.
However, for threads, when it does a pthread_exit(&exit_status) call, the
kernel is not aware of the exit status with which pthread_exit is ca
net-next 2/3] connector/cn_proc: Kunit tests for threads
hash table
On Fri, Oct 11, 2024 at 05:45:31PM -0700, Anjali Kulkarni wrote:
> Kunit tests to test hash table add, delete, duplicate add and delete.
> Add following configs and compile kernel code:
>
> CONFIG_CONNECTOR=y
> CON
gt; --- /dev/null
> +++ b/lib/cn_hash_test.c
> @@ -0,0 +1,167 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * KUnit test for the connector threads hashtable code.
> + *
> + * Copyright (c) 2024 Oracle and/or its affiliates.
> + * Author: Anjali Kulkarni
> + */
>
n with it.
> Exiting thread can call this either when it wants to call pthread_exit()
> with non-zero value or from signal handler.
>
> Add a new file cn_hash.c which implements a hash table storing the exit
> codes of abnormally exiting threads, received by the system call above.
> The
Test to check if setting PROC_CN_MCAST_NOTIFY in proc connector API, allows
a thread's non-zero exit status to be returned to proc_filter.
The threads.c program creates 2 child threads. 1st thread handles signal
SIGSEGV, and 2nd thread needs to indicate some error condition (value 1)
t
t.c
new file mode 100644
index ..2687492864ed
--- /dev/null
+++ b/lib/cn_hash_test.c
@@ -0,0 +1,167 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * KUnit test for the connector threads hashtable code.
+ *
+ * Copyright (c) 2024 Oracle and/or its affiliates.
+ * Author: Anjali K
()
with non-zero value or from signal handler.
Add a new file cn_hash.c which implements a hash table storing the exit
codes of abnormally exiting threads, received by the system call above.
The key used for the hash table is the pid of the thread, so when the
thread actually exits, we lookup it's p
Recently we committed a fix to allow processes to receive notifications for
non-zero exits via the process connector module. Commit is a4c9a56e6a2c.
However, for threads, when it does a pthread_exit(&exit_status) call, the
kernel is not aware of the exit status with which pthread_exit is ca
Hi Anjali,
kernel test robot noticed the following build warnings:
[auto build test WARNING on net-next/main]
url:
https://github.com/intel-lab-lkp/linux/commits/Anjali-Kulkarni/connector-cn_proc-Handle-threads-for-proc-connector/20240920-081249
base: net-next/main
patch link:
https
> On Sep 20, 2024, at 11:44 AM, Oleg Nesterov wrote:
>
> On 09/20, Anjali Kulkarni wrote:
>>
>>> On Sep 20, 2024, at 4:00 AM, Oleg Nesterov wrote:
>>>
>>> I don't think you can use task_struct->exit_code. If this task is ptraced,
>>> it can be changed/cleared in, say, ptrace_stop() after PRO
On 09/20, Anjali Kulkarni wrote:
>
> > On Sep 20, 2024, at 4:00 AM, Oleg Nesterov wrote:
> >
> > I don't think you can use task_struct->exit_code. If this task is ptraced,
> > it can be changed/cleared in, say, ptrace_stop() after PROC_CN_MCAST_NOTIFY.
> >
>
> Thank you, that’s a good point! Howev
> On Sep 20, 2024, at 4:00 AM, Oleg Nesterov wrote:
>
> On 09/19, Anjali Kulkarni wrote:
>>
>> @@ -413,6 +416,10 @@ static void cn_proc_mcast_ctl(struct cn_msg *msg,
>> if (msg->len == sizeof(*pinput)) {
>> pinput = (struct proc_input *)msg->data;
>> mc_op = pinp
On 09/19, Anjali Kulkarni wrote:
>
> @@ -413,6 +416,10 @@ static void cn_proc_mcast_ctl(struct cn_msg *msg,
> if (msg->len == sizeof(*pinput)) {
> pinput = (struct proc_input *)msg->data;
> mc_op = pinput->mcast_op;
> + if (mc_op == PROC_CN_MCAST_NOTIFY
Add a new type PROC_CN_MCAST_NOTIFY to proc connector API, which allows a
thread to notify the kernel that it has exited abnormally. Thread can also
send the exit status code it wants returned in the notification with it.
Exiting thread can call this either when it wants to call pthread_exit()
with
Recently we committed a fix to allow processes to receive notifications for
non-zero exits via the process connector module. Commit is a4c9a56e6a2c.
However, for threads, when it does a pthread_exit(&exit_status) call, the
kernel is not aware of the exit status with which pthread_exit is ca
Test to check if setting PROC_CN_MCAST_NOTIFY in proc connector API, allows
a thread's non-zero exit status to be returned to proc_filter.
The threads.c program creates 2 child threads. 1st thread handles signal
SIGSEGV, and 2nd thread needs to indicate some error condition (value 1)
t
OpenRISC exception handling sends signals to user processes on floating
point exceptions and trap instructions (for debugging) among others.
There is a bug where the trap handling logic may send signals to kernel
threads, we should not send these signals to kernel threads, if that
happens we treat
r, each individual kworker
> > > can potentially have CPU share equal to the entire UX cgroup.
> > >
> > > -kworker/0:0
> > > -kworker/1:0
> > > - UX
> > > Task-A
> > > Task-B
> > > - background
> > > Task-X
>
Hello,
On Tue, Apr 6, 2021 at 5:49 PM Bayduraev, Alexey V
wrote:
>
>
> Provide --threads option in perf record command line interface.
> The option can have a value in the form of masks that specify
> cpus to be monitored with data streaming threads and its layout
> in system t
:00
Committer: Peter Zijlstra
CommitterDate: Fri, 09 Apr 2021 18:02:20 +02:00
sched/fair: Ignore percpu threads for imbalance pulls
During load balance, LBF_SOME_PINNED will be set if any candidate task
cannot be detached due to CPU affinity constraints. This can result in
setting env->
:00
Committer: Peter Zijlstra
CommitterDate: Fri, 09 Apr 2021 13:52:10 +02:00
sched/fair: Ignore percpu threads for imbalance pulls
During load balance, LBF_SOME_PINNED will be set if any candidate task
cannot be detached due to CPU affinity constraints. This can result in
setting env->
:00
Committer: Peter Zijlstra
CommitterDate: Thu, 08 Apr 2021 23:09:44 +02:00
sched/fair: Ignore percpu threads for imbalance pulls
During load balance, LBF_SOME_PINNED will be set if any candidate task
cannot be detached due to CPU affinity constraints. This can result in
setting env->
On Tue, Apr 06, 2021 at 11:49:06AM +0300, Bayduraev, Alexey V wrote:
SNIP
> Suggested-by: Jiri Olsa
> Suggested-by: Namhyung Kim
> Signed-off-by: Alexey Bayduraev
> ---
> tools/include/linux/bitmap.h | 11 ++
> tools/lib/bitmap.c | 14 ++
> tools/perf/builtin-record.c | 317 +
> + err = write(thread->pipes.ack[1], &msg, sizeof(msg));
> + if (err == -1)
> + pr_err("threads[%d]: failed to notify on start. Error %m",
> thread->tid);
It might be safer to not use %m. I'm not sure if all the non glibc
libcs that people use support it.
From: Lingutla Chandrasekhar
During load balance, LBF_SOME_PINNED will be set if any candidate task
cannot be detached due to CPU affinity constraints. This can result in
setting env->sd->parent->sgc->group_imbalance, which can lead to a group
being classified as group_imbalanced (rather than any
. This helps in prioritizing
> > Task-A and Task-B over Task-X and Task-Y. However, each individual kworker
> > can potentially have CPU share equal to the entire UX cgroup.
> >
> > -kworker/0:0
> > -kworker/1:0
> > - UX
> > Task-A
> > Task-B
>
d Task-Y. However, each individual kworker
> can potentially have CPU share equal to the entire UX cgroup.
>
> -kworker/0:0
> -kworker/1:0
> - UX
> Task-A
> Task-B
> - background
> Task-X
> Task-Y
> Hence we want to move all kernel threads to a
On 06/04/21 17:35, Dietmar Eggemann wrote:
> On 01/04/2021 21:30, Valentin Schneider wrote:
>> From: Lingutla Chandrasekhar
>>
>> During load balance, LBF_SOME_PINNED will bet set if any candidate task
>
> nitpick; s/bet/be ?
>
Yes indeed...
> [...]
>
> Reviewed-by: Dietmar Eggemann
On 01/04/2021 21:30, Valentin Schneider wrote:
> From: Lingutla Chandrasekhar
>
> During load balance, LBF_SOME_PINNED will bet set if any candidate task
nitpick; s/bet/be ?
[...]
Reviewed-by: Dietmar Eggemann
However, there are many kernel tasks stuck in the
> > root cgroup after the boot.
> >
> > We see all kworker threads are in the root cpu cgroup. This is because,
> > tasks with PF_NO_SETAFFINITY flag set are forbidden from cgroup migration.
> > This restriction is in pl
m higher share
> compared to the other tasks inside important cgroups. This is mitigated
> by moving all tasks inside root cgroup to a different cgroup after
> Android is booted. However, there are many kernel tasks stuck in the
> root cgroup after the boot.
>
> We see all kworker th
g all tasks inside root cgroup to a different cgroup after
Android is booted. However, there are many kernel tasks stuck in the
root cgroup after the boot.
We see all kworker threads are in the root cpu cgroup. This is because,
tasks with PF_NO_SETAFFINITY flag set are forbidden from cgroup migration.
booted. However, there are many kernel tasks stuck in the
> > root cgroup after the boot.
> >
> > We see all kworker threads are in the root cpu cgroup. This is because,
> > tasks with PF_NO_SETAFFINITY flag set are forbidden from cgroup migration.
> > This restric
m higher share
> compared to the other tasks inside important cgroups. This is mitigated
> by moving all tasks inside root cgroup to a different cgroup after
> Android is booted. However, there are many kernel tasks stuck in the
> root cgroup after the boot.
>
> We see all kwo
g all tasks inside root cgroup to a different cgroup after
Android is booted. However, there are many kernel tasks stuck in the
root cgroup after the boot.
We see all kworker threads are in the root cpu cgroup. This is because,
tasks with PF_NO_SETAFFINITY flag set are forbidden from cgroup migration.
Provide --threads option in perf record command line interface.
The option can have a value in the form of masks that specify
cpus to be monitored with data streaming threads and its layout
in system topology. The masks can be filtered using cpu mask
provided via -C option.
The specification
(err == -1)
+ pr_err("threads[%d]: failed to notify on start. Error %m",
thread->tid);
+
+ pr_debug("threads[%d]: started on cpu=%d\n", thread->tid,
sched_getcpu());
+
+ pollfd = &thread->pollfd;
+ ctlfd_pos = thread->ctlfd_pos;
+
+ for
Signal thread to terminate by closing write fd of msg pipe.
Receive THREAD_MSG__READY message as the confirmation of the
thread's termination. Stop threads created for parallel trace
streaming prior their stats processing.
Signed-off-by: Alexey Bayduraev
---
tools/perf/builtin-record.c
Am 01.04.21 um 18:24 schrieb Linus Torvalds:
> On Thu, Apr 1, 2021 at 9:00 AM Stefan Metzmacher wrote:
>>
>> I haven't tried it, but it seems gdb tries to use PTRACE_PEEKUSR
>> against the last thread tid listed under /proc//tasks/ in order to
>> get the architecture for the userspace application
On Thu, 1 Apr 2021 at 21:30, Valentin Schneider
wrote:
>
> From: Lingutla Chandrasekhar
>
> During load balance, LBF_SOME_PINNED will bet set if any candidate task
> cannot be detached due to CPU affinity constraints. This can result in
> setting env->sd->parent->sgc->group_imbalance, which can l
1 - 100 of 1585 matches
Mail list logo
