Hello Joshua.
On Fri, Aug 30, 2024 at 07:19:37AM GMT, Joshua Hahn
wrote:
> Exposing this metric will allow users to accurately probe the niced CPU
> metric for each workload, and make more informed decisions when
> directing higher priority tasks.
I'm afraid I can't still appreciate exposing th
Hi.
On Tue, Aug 20, 2024 at 03:55:35PM GMT, Waiman Long wrote:
> The prstate_housekeeping_conflict() function does check the
> HK_TYPE_DOMAIN housekeeping cpumask to make sure that CPUs outside of it
> can only be used in isolated partition.
> Given the fact that we are going to make housekeeping
Hello.
On Fri, Aug 23, 2024 at 01:05:16PM GMT, joshuahahnjoshua.ha...@gmail.com wrote:
> Niced CPU usage is a metric reported in host-level /proc/stat, but is
> not reported in cgroup-level statistics in cpu.stat. However, when a
> host contains multiple tasks across different workloads, it become
9 files changed, 174 insertions(+), 27 deletions(-)
Thanks for the fixups, you can add
Reviewed-by: Michal Koutný
(I believe the test failure in the other thread is unrelated.)
signature.asc
Description: PGP signature
Hello.
On Mon, Jul 29, 2024 at 10:37:43AM GMT, David Finkel wrote:
> Extend two existing tests to cover extracting memory usage through the
> newly mutable memory.peak and memory.swap.peak handlers.
BTW do the tests pass for you?
I gave it a try (v6.11-rc1+your patches)
$ grep "not ok 2" -B30
Hello David.
On Wed, Jul 24, 2024 at 12:19:41PM GMT, David Finkel wrote:
> Writing a specific string to the memory.peak and memory.swap.peak
> pseudo-files reset the high watermark to the current usage for
> subsequent reads through that same fd.
This is elegant and nice work! (Caught my attenti
Hello Jianfeng.
On Tue, Jul 16, 2024 at 11:27:39AM GMT, xiujianfeng
wrote:
> On 2024/7/3 14:59, xiujianfeng wrote:
...
> > for (; parent_pids(p); p = parent_pids(p)) {
> > if (p == pids_over_limit) {
> > limit = true;
> > at
This commit adds (and wires in) new test program for checking basic pids
controller functionality -- restricting tasks in a cgroup and correct
event counting.
Signed-off-by: Michal Koutný
---
tools/testing/selftests/cgroup/.gitignore | 1 +
tools/testing/selftests/cgroup/Makefile| 2
The pids.events file should honor the hierarchy, so make the events
propagate from their origin up to the root on the unified hierarchy. The
legacy behavior remains non-hierarchical.
Signed-off-by: Michal Koutný
---
Documentation/admin-guide/cgroup-v2.rst | 9 +++--
kernel/cgroup/pids.c
This will reduce number of conflicts when modifying the lists.
Signed-off-by: Michal Koutný
---
tools/testing/selftests/cgroup/.gitignore | 10 +-
tools/testing/selftests/cgroup/Makefile | 23 ---
2 files changed, 17 insertions(+), 16 deletions(-)
diff --git a
://lore.kernel.org/r/20200205134426.10570-1-mkou...@suse.com)
- implemented pids.events.local (Tejun)
- added migration charging
[1] https://lore.kernel.org/r/20230202155626.1829121-1-han...@cmpxchg.org/
Michal Koutný (5):
cgroup/pids: Separate semantics of pids.events related to pids.max
cgr
it changes semantics of the original "max" event, introduce this
change only in the v2 API of the controller and add a cgroup2 mount
option to revert to the legacy behavior.
Signed-off-by: Michal Koutný
---
Documentation/admin-guide/cgroup-v1/pids.rst | 3 +-
Documentation/admin-guide/cgr
: Michal Koutný
---
Documentation/admin-guide/cgroup-v2.rst | 5 ++
kernel/cgroup/pids.c| 89 -
2 files changed, 76 insertions(+), 18 deletions(-)
diff --git a/Documentation/admin-guide/cgroup-v2.rst
b/Documentation/admin-guide/cgroup-v2.rst
index
Atomic counters are in kzalloc'd struct. They are zeroed already and
atomic64_t does not need special initialization
(cf kernel/trace/trace_clock.c:trace_counter).
Signed-off-by: Michal Koutný
---
kernel/cgroup/pids.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/kernel/cgroup/pid
This commit adds (and wires in) new test program for checking basic pids
controller functionality -- restricting tasks in a cgroup and correct
event counting.
Signed-off-by: Michal Koutný
---
tools/testing/selftests/cgroup/.gitignore | 1 +
tools/testing/selftests/cgroup/Makefile| 2
This will reduce number of conflicts when modifying the lists.
Signed-off-by: Michal Koutný
---
tools/testing/selftests/cgroup/.gitignore | 10 +-
tools/testing/selftests/cgroup/Makefile | 23 ---
2 files changed, 17 insertions(+), 16 deletions(-)
diff --git a
it changes semantics of the original "max" event, introduce this
change only in the v2 API of the controller and add a cgroup2 mount
option to revert to the legacy behavior.
Signed-off-by: Michal Koutný
---
Documentation/admin-guide/cgroup-v1/pids.rst | 3 +-
Documentation/admin-guide/cgr
The pids.events file should honor the hierarchy, so make the events
propagate from their origin up to the root on the unified hierarchy. The
legacy behavior remains non-hierarchical.
Signed-off-by: Michal Koutný
---
Documentation/admin-guide/cgroup-v2.rst | 2 +-
kernel/cgroup/pids.c
ches
- drop RFC prefix
Changes from v2
(https://lore.kernel.org/r/20200205134426.10570-1-mkou...@suse.com)
- implemented pids.events.local (Tejun)
- added migration charging
[1] https://lore.kernel.org/r/20230202155626.1829121-1-han...@cmpxchg.org/
Michal Koutný (6):
cgroup/pids: Remove supe
: Michal Koutný
---
kernel/cgroup/pids.c | 88 +++-
1 file changed, 71 insertions(+), 17 deletions(-)
diff --git a/kernel/cgroup/pids.c b/kernel/cgroup/pids.c
index 4ad28109c1c8..6cd15c3785d4 100644
--- a/kernel/cgroup/pids.c
+++ b/kernel/cgroup/pids.c
On Mon, Apr 08, 2024 at 07:55:38AM -1000, Tejun Heo wrote:
> The whole series make sense to me.
Including the migration charging?
(Asking whether I should keep it stacked in v4 posting.)
Thanks,
Michal
signature.asc
Description: PGP signature
On Wed, Apr 10, 2024 at 05:26:18PM -0700, Yonghong Song
wrote:
> This is not true.
Oh, I misunderstood a manpage, I can see now it's not for any syscall.
> More syscalls can be added (through kfunc) if there is a use case for that.
Thus, I don't want to open this up.
Michal
signature.asc
De
Hi.
On Tue, Apr 02, 2024 at 07:20:45PM +0100, Djalal Harouni
wrote:
> Thanks yes, I would expect freeze to behave like signal, and if one
> wants to block immediately there is the LSM override return. The
> selftest attached tries to do exactly that.
Are you refering to this part:
int
On Mon, Apr 08, 2024 at 04:53:11PM +0500, Muhammad Usama Anjum
wrote:
> ksft_test_result_report(tests[i].fn(root), tests[i].name)
$ git grep ksft_test_result_report v6.9-rc3 --
(empty result)
I can't find that helper. Is that in some devel repositories?
Michal
signature.asc
Description: PGP
On Sun, Apr 07, 2024 at 02:37:44AM +0500, Muhammad Usama Anjum
wrote:
> The
> ksft_print_header();
> ksft_set_plan(total_number_of_tests);
> are missing. Please use all of the ksft APIs to make the test TAP compliant.
Will do.
> > + for (i = 0; i < ARRAY_SIZE(tests); i++) {
> > +
This will reduce number of conflicts when modifying the lists.
Signed-off-by: Michal Koutný
---
tools/testing/selftests/cgroup/Makefile | 23 ---
1 file changed, 12 insertions(+), 11 deletions(-)
diff --git a/tools/testing/selftests/cgroup/Makefile
b/tools/testing
Hierarchical counting of events is not practical for watching when a
particular pids.max is being hit. Therefore introduce .local flavor of
events file (akin to memory controller) that collects only events
relevant to given cgroup.
Signed-off-by: Michal Koutný
---
kernel/cgroup/pids.c | 41
202155626.1829121-1-han...@cmpxchg.org/
Michal Koutný (9):
cgroup/pids: Remove superfluous zeroing
cgroup/pids: Separate semantics of pids.events related to pids.max
cgroup/pids: Make event counters hierarchical
cgroup/pids: Add pids.events.local
selftests: cgroup: Lexicographic order in M
This adds a couple of tests to check enforcing of limits in pids
controller upon migration. When the new option does not exist, the test
is skipped.
Signed-off-by: Michal Koutný
---
tools/testing/selftests/cgroup/test_pids.c | 117 -
1 file changed, 116 insertions(+), 1
ent of common ancestor and above is not affected by
migration, so deliberatly ignore pre-existing pids.current > pids.max).
This change of behavior is hidden behind cgroup2 mount option and
the default is unchanged, pids.max won't affect migrations.
Signed-off-by: Michal Koutný
---
Do
This commit adds (and wires in) new test program for checking basic pids
controller functionality -- restricting tasks in a cgroup and correct
event counting.
Signed-off-by: Michal Koutný
---
tools/testing/selftests/cgroup/Makefile| 2 +
tools/testing/selftests/cgroup/test_pids.c | 187
The pids.events file should honor the hierarchy, so make the events
propagate from their origin up to the root on the unified hierarchy. The
v1 behavior remains non-hierarchical.
Signed-off-by: Michal Koutný
---
Documentation/admin-guide/cgroup-v2.rst | 4 ++-
kernel/cgroup/pids.c
uce
this change only in the v2 API of the controller.
Signed-off-by: Michal Koutný
---
Documentation/admin-guide/cgroup-v1/pids.rst | 3 +-
Documentation/admin-guide/cgroup-v2.rst | 12
kernel/cgroup/pids.c | 71
3 files changed, 73 in
No functional change intended. This rework reduces modifications of pids
counters only to a minimal subtree of uncharged/charged cgroups.
Signed-off-by: Michal Koutný
---
kernel/cgroup/pids.c | 80 ++--
1 file changed, 47 insertions(+), 33 deletions
Atomic counters are in kzalloc'd struct. They are zeroed already and
atomic64_t does not need special initialization
(cf kernel/trace/trace_clock.c:trace_counter).
Signed-off-by: Michal Koutný
---
kernel/cgroup/pids.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/kernel/cgroup/pid
On Wed, Apr 03, 2024 at 10:47:33AM -0400, Waiman Long
wrote:
> should be rare these days as it will only apply in the case of cgroup
> v1 under certain condtion,
Could the migration be simply omitted it those special cases?
(Tasks remain in cpusets with empty cpusets -- that already happens in
On Wed, Apr 03, 2024 at 04:26:38PM +0200, Valentin Schneider
wrote:
> Also, I gave Michal's patch a try and it looks like it's introducing a
Thank you.
> cgroup_threadgroup_rwsem -> cpuset_mutex
> ordering from
> cgroup_transfer_tasks_locked()
> `\
> percpu_down_write(&cgroup_threadgr
On Tue, Apr 02, 2024 at 11:30:11AM -0400, Waiman Long
wrote:
> Yes, there is a potential that a cpus_read_lock() may be called leading to
> deadlock. So unless we reverse the current cgroup_mutex --> cpu_hotplug_lock
> ordering, it is not safe to call cgroup_transfer_tasks() directly.
I see that
Hello.
On Wed, Mar 27, 2024 at 11:53:22PM +0100, Djalal Harouni
wrote:
> ...
> For some cases we want to freeze the cgroup of a task based on some
> signals, doing so from bpf is better than user space which could be
> too late.
Notice that freezer itself is not immediate -- tasks are frozen as
Hello Waiman.
(I have no opinion on the overall locking reworks, only the bits about
v1 migrations caught my attention.)
On Mon, Apr 01, 2024 at 10:58:57AM -0400, Waiman Long
wrote:
...
> @@ -4383,12 +4377,20 @@ hotplug_update_tasks_legacy(struct cpuset *cs,
> /*
>* Move tasks to
Hello Waiman.
On Wed, Jan 17, 2024 at 11:35:03AM -0500, Waiman Long
wrote:
> This patch series is based on the RFC patch from Frederic [1]. Instead
> of offering RCU_NOCB as a separate option, it is now lumped into a
> root-only cpuset.cpus.isolation_full flag that will enable all the
> addition
41 matches
Mail list logo
