har *argv[])
> if (keypress)
> delay = -1;
>
> + check_core_sched();
> +
> srand(time(NULL));
>
> /* put into separate process group */
> --
> 2.43.5
So assuming a return code of 4 means skip (and I believe you stated that
affirmatively before), then this
should solve the problem. Thanks for fixing this.
Reviewed-by: Chris Hyser
-chrish
>From: Sinadin Shan
>Sent: Monday, February 24, 2025 7:10 AM
>To: Shrikanth Hegde; sh...@kernel.org
>Cc: linux-kselft...@vger.kernel.org; linux-kernel@vger.kernel.org; Chris Hyser
>Subject: Re: [PATCH v2 2/2] selftests: sched: skip cs_prctl_test for systems
>with core schedul
From: Chris Hyser
Sent: Thursday, February 20, 2025 11:21 PM
To: Sinadin Shan; Shrikanth Hegde
Cc: linux-kselft...@vger.kernel.org; linux-kernel@vger.kernel.org;
sh...@kernel.org
Subject: Re: [PATCH] selftests: sched: add sched as a default selftest target
>
> From: Sinadin Shan
From: Sinadin Shan
Sent: Thursday, February 20, 2025 11:23 AM
To: Chris Hyser; Shrikanth Hegde
Cc: linux-kselft...@vger.kernel.org; linux-kernel@vger.kernel.org;
sh...@kernel.org
Subject: Re: [PATCH] selftests: sched: add sched as a default selftest target
>> I guess my question is w
From: Sinadin Shan
Sent: Thursday, February 20, 2025 9:52 AM
To: Shrikanth Hegde; Chris Hyser
Cc: linux-kselft...@vger.kernel.org; linux-kernel@vger.kernel.org;
sh...@kernel.org
Subject: Re: [PATCH] selftests: sched: add sched as a default selftest target
> On 20-02-2025 01:15 pm, Shrika
> From: Sinadin Shan
> Sent: Wednesday, February 19, 2025 1:46 AM
> To: sh...@kernel.org
> Cc: linux-kselft...@vger.kernel.org; linux-kernel@vger.kernel.org; Chris
> Hyser; Sinadin Shan
> Subject: [PATCH] selftests: sched: add sched as a default selftest target
>
> The s
On 3/22/21 2:33 PM, Peter Zijlstra wrote:
On Mon, Mar 22, 2021 at 01:57:48PM -0400, Chris Hyser wrote:
On 3/20/21 11:46 AM, Peter Zijlstra wrote:
On Fri, Mar 19, 2021 at 04:32:49PM -0400, Joel Fernandes (Google) wrote:
From: Josh Don
Adds per-task and per-cgroup interfaces for specifying
On 3/20/21 11:46 AM, Peter Zijlstra wrote:
On Fri, Mar 19, 2021 at 04:32:49PM -0400, Joel Fernandes (Google) wrote:
From: Josh Don
Adds per-task and per-cgroup interfaces for specifying which tasks can
co-execute on adjacent SMT hyperthreads via core scheduling.
The per-task interface hooks a
On 2/24/21 10:47 AM, chris hyser wrote:
On 2/24/21 8:52 AM, chris hyser wrote:
On 2/24/21 8:02 AM, Chris Hyser wrote:
However, it means that overall throughput of your binary is cut in
~half, since none of the threads can share a core. Note that I never
saw an indefinite deadlock, just ~2x
On 2/24/21 8:52 AM, chris hyser wrote:
On 2/24/21 8:02 AM, Chris Hyser wrote:
However, it means that overall throughput of your binary is cut in
~half, since none of the threads can share a core. Note that I never
saw an indefinite deadlock, just ~2x runtime for your binary vs th > cont
On 2/24/21 8:02 AM, Chris Hyser wrote:
However, it means that overall throughput of your binary is cut in
~half, since none of the threads can share a core. Note that I never
saw an indefinite deadlock, just ~2x runtime for your binary vs th > control. I've verified that both a)
On 2/24/21 12:15 AM, Josh Don wrote:
On Tue, Feb 23, 2021 at 11:26 AM Chris Hyser wrote:
On 2/23/21 4:05 AM, Peter Zijlstra wrote:
On Mon, Feb 22, 2021 at 11:00:37PM -0500, Chris Hyser wrote:
On 1/22/21 8:17 PM, Joel Fernandes (Google) wrote:
While trying to test the new prctl() code I&#
On 2/23/21 4:05 AM, Peter Zijlstra wrote:
On Mon, Feb 22, 2021 at 11:00:37PM -0500, Chris Hyser wrote:
On 1/22/21 8:17 PM, Joel Fernandes (Google) wrote:
While trying to test the new prctl() code I'm working on, I ran into a bug I
chased back into this v10 code. Under a fair amount of s
On 1/22/21 8:17 PM, Joel Fernandes (Google) wrote:
+static void __sched_core_update_cookie(struct task_struct *p)
+{
+ struct rb_node *parent, **node;
+ struct sched_core_cookie *node_core_cookie, *match;
+ static const struct sched_core_cookie zero_cookie;
+ struct sched_
On 2/5/21 5:43 AM, Peter Zijlstra wrote:
On Thu, Feb 04, 2021 at 03:52:55PM -0500, Chris Hyser wrote:
A second complication was a decision that new processes (not threads) do not
inherit their parents cookie. Thus forking is also not a means to share a
cookie. Basically with a "from
On 2/4/21 8:57 AM, Peter Zijlstra wrote:
On Fri, Jan 22, 2021 at 08:17:01PM -0500, Joel Fernandes (Google) wrote:
+/* Request the scheduler to share a core */
+#define PR_SCHED_CORE_SHARE59
+# define PR_SCHED_CORE_CLEAR 0 /* clear core_sched cookie of pid */
+# define PR_S
On 12/14/20 6:25 PM, Joel Fernandes wrote:
On Mon, Dec 14, 2020 at 02:44:09PM -0500, chris hyser wrote:
On 12/14/20 2:31 PM, Joel Fernandes wrote:
diff --git a/kernel/sched/debug.c b/kernel/sched/debug.c
index cffdfab..50c31f3 100644
--- a/kernel/sched/debug.c
+++ b/kernel/sched/debug.c
On 12/14/20 6:25 PM, Joel Fernandes wrote:
On Mon, Dec 14, 2020 at 02:44:09PM -0500, chris hyser wrote:
On 12/14/20 2:31 PM, Joel Fernandes wrote:
diff --git a/kernel/sched/debug.c b/kernel/sched/debug.c
index cffdfab..50c31f3 100644
--- a/kernel/sched/debug.c
+++ b/kernel/sched/debug.c
On 12/14/20 2:31 PM, Joel Fernandes wrote:
diff --git a/kernel/sched/debug.c b/kernel/sched/debug.c
index cffdfab..50c31f3 100644
--- a/kernel/sched/debug.c
+++ b/kernel/sched/debug.c
@@ -1030,6 +1030,7 @@ void proc_sched_show_task(struct task_struct *p, struct
pid_namespace *ns,
#ifdef CON
| 6 +-
tools/include/uapi/linux/prctl.h | 3 +
tools/testing/selftests/sched/test_coresched.c | 14 +++-
9 files changed, 136 insertions(+), 54 deletions(-)
-- >8 --
>From beca9bae6750a66d8c30bbed1d6b8b26b2da05f4 Mon Sep 17 00:00:00 2001
From: chris hyser
Date
On 12/6/20 12:34 PM, Joel Fernandes wrote:
Looks ok to me except the missing else { } clause you found. Also, maybe
dest/src can be renamed to from/to to make meaning of variables more clear?
yes.
Also looking forward to the docs/test updates.
on it.
Thanks.
-chrish
On 12/2/20 4:47 PM, Chris Hyser wrote:
+ get_task_struct(task);
+
+ /*
+* Check if this process has the right to modify the specified
+* process. Use the regular "ptrace_may_access()" checks.
+*/
+ if (!ptrace_may_access(task, PTRACE_MODE_READ
well.
-chrish
---8<---
>From ec3d6506fee89022d93789e1ba44d49c1b1b04dd Mon Sep 17 00:00:00 2001
From: chris hyser
Date: Tue, 10 Nov 2020 15:35:59 -0500
Subject: [PATCH] sched: Provide a more extensive prctl interface for core
scheduling.
The current prctl interface is a "
On 11/4/20 5:30 PM, chris hyser wrote:
On 10/19/20 9:43 PM, Joel Fernandes (Google) wrote:
In order to prevent interference and clearly support both per-task and CGroup
APIs, split the cookie into 2 and allow it to be set from either per-task, or
CGroup API. The final cookie is the combined
thread clone and causes underflow for both the enable flag itself
and for cookie ref counts.
So just zero it in __sched_fork().
-chris
PATCH] sched: zero out the core scheduling cookie on clone
From: chris hyser
As the cookie is reference counted, even if inherited, zero this and allow
explic
On 10/19/20 9:43 PM, Joel Fernandes (Google) wrote:
In order to prevent interference and clearly support both per-task and CGroup
APIs, split the cookie into 2 and allow it to be set from either per-task, or
CGroup API. The final cookie is the combined value of both and is computed when
the stop-
On 10/19/20 9:43 PM, Joel Fernandes (Google) wrote:
During exit, we have to free the references to a cookie that might be shared by
many tasks. This commit therefore ensures when the task_struct is released, any
references to cookies that it holds are also released.
Tested-by: Julien Desfossez
On 9/16/20 8:57 AM, Li, Aubrey wrote:
Here are the uperf results of the various patchsets. Note, that disabling smt
is better for these tests and that that presumably reflects the overall
overhead of core scheduling which went from bad to really bad. The primary
focus in this email is to start
On 9/16/20 10:24 AM, chris hyser wrote:
On 9/16/20 8:57 AM, Li, Aubrey wrote:
Here are the uperf results of the various patchsets. Note, that disabling smt is better for these tests and that that
presumably reflects the overall overhead of core scheduling which went from bad to really bad. The
On 8/28/20 3:51 PM, Julien Desfossez wrote:
From: Aaron Lu
This patch provides a vruntime based way to compare two cfs task's
priority, be it on the same cpu or different threads of the same core.
When the two tasks are on the same CPU, we just need to find a common
cfs_rq both sched_entities
On 8/24/20 4:53 PM, chris hyser wrote:
On 8/21/20 11:01 PM, Joel Fernandes wrote:
Hello!
Core-scheduling aims to allow making it safe for more than 1 task that trust
each other to safely share hyperthreads within a CPU core [1]. This results
in a performance improvement for workloads that
code
and attack both the guest and the host systems sharing the core.
Usecase 4: Oracle - Setting a sub-CGroup as trusted (cookie 0). Chris Hyser
talked to me on IRC that in a CGroup hierarcy, some CGroups should be allowed
to not have to share its parent's CGroup tag. In fact, it should be
On 7/20/20 4:47 AM, Dietmar Eggemann wrote:
On 10/07/2020 01:08, chris hyser wrote:
[...]
D) Desired behavior:
Reduce the maximum wake-up latency of designated CFS tasks by skipping
some or all of the idle CPU and core searches by setting a maximum idle
CPU search value (maximum loop
> A) Name:
Skipping Idle Cores and CPU Search
> B) Target behavior:
Finding idle CPUs in the CFS scheduler for scheduling awakened tasks increases system throughput at the expense of
additional wake-up latency. For the majority of processes this is a reasonable trade-off. Some communication t
On 11/09/2017 01:05 PM, Serge E. Hallyn wrote:
Would the existing capability bounding set not suffice for that?
The 'permanent' bounding set turns out to not be a good fit for
the problem being discussed in this thread, but please feel free
to start a new thread if you want to discuss your use c
On 11/06/2017 10:23 PM, Serge E. Hallyn wrote:
I think I definately prefer what I mentioned in the email to Boris.
Basically a "permanent capability bounding set". The normal bounding
set gets reset to a full set on every new user_ns creation. In this
proposal, it would instead be set to the ca
Hi All,
Technically, this is a broader question than just SPARC where I initially
sent this. I'm sending this here and dropping the test patch as it was
SPARC only and this is primarily a sysfs generic platform description
question.
Before SPARC M7, the notion of core_siblings on SPARC was both
Hi All,
Technically, this is a broader question than just SPARC where I initially
sent this. I'm sending this here and dropping the test patch as it was
SPARC only and this is primarily a sysfs generic platform description
question.
Before SPARC M7, the notion of core_siblings on SPARC was both
Hi All,
Technically, this is a broader question than just SPARC where I initially
sent this. I'm sending this here and dropping the test patch as it was
SPARC only and this is primarily a sysfs generic platform description
question.
Before SPARC M7, the notion of core_siblings on SPARC was both
39 matches
Mail list logo
