Re: [PATCH v5 0/5] pids controller events rework

2024-05-26 Thread Tejun Heo
On Tue, May 21, 2024 at 11:21:25AM +0200, Michal Koutný wrote: > Michal Koutný (5): > 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 Makefile

Re: [PATCH v4 08/66] selftests/cgroup: Drop define _GNU_SOURCE

2024-05-16 Thread Tejun Heo
Hello, On Thu, May 16, 2024 at 10:31:13AM -0600, Shuah Khan wrote: > I am exploring options and leaning towards reverting the patch > > daef47b89efd ("selftests: Compile kselftest headers with -D_GNU_SOURCE") > > Your amending the PR helps me if I have to send revert. I am sorry > for the

Re: [PATCH v4 08/66] selftests/cgroup: Drop define _GNU_SOURCE

2024-05-16 Thread Tejun Heo
On Thu, May 16, 2024 at 09:50:06AM -0600, Shuah Khan wrote: > On 5/13/24 11:02, Tejun Heo wrote: > > On Fri, May 10, 2024 at 12:06:25AM +, Edward Liaw wrote: > > > _GNU_SOURCE is provided by lib.mk, so it should be dropped to prevent > > > redefinition warnin

Re: [PATCH v4 08/66] selftests/cgroup: Drop define _GNU_SOURCE

2024-05-13 Thread Tejun Heo
On Fri, May 10, 2024 at 12:06:25AM +, Edward Liaw wrote: > _GNU_SOURCE is provided by lib.mk, so it should be dropped to prevent > redefinition warnings. > > Signed-off-by: Edward Liaw Applied to cgroup/for-6.10. Thanks. -- tejun

Re: [PATCH 0/4] selftests/cgroups: fix clang build failures, warnings

2024-05-03 Thread Tejun Heo
On Thu, May 02, 2024 at 08:51:01PM -0700, John Hubbard wrote: > Hi, > > Just a bunch of fixes as part of my work to make selftests build cleanly > with clang. > > Enjoy! > > thanks, > John Hubbard > > > John Hubbard (4): > selftests/cgroup: fix clang build failures for abs() calls >

Re: [PATCH v4 0/6] pids controller events rework

2024-04-16 Thread Tejun Heo
On Tue, Apr 16, 2024 at 04:20:08PM +0200, Michal Koutný wrote: > This makes pids.events:max affine to pids.max limit. > > How are the new events supposed to be useful? > > - pids.events.local:max > - tells that cgroup's limit is hit (too tight?) > - pids.events:* > - "only" directs top-down

Re: [PATCH v4 4/6] cgroup/pids: Add pids.events.local

2024-04-16 Thread Tejun Heo
On Tue, Apr 16, 2024 at 04:20:12PM +0200, Michal Koutný wrote: > struct cgroup_subsys pids_cgrp_subsys = { > .css_alloc = pids_css_alloc, > .css_free = pids_css_free, > @@ -416,5 +469,6 @@ struct cgroup_subsys pids_cgrp_subsys = { > .cancel_fork= pids_cancel_fork,

Re: [PATCH v4 2/6] cgroup/pids: Separate semantics of pids.events related to pids.max

2024-04-16 Thread Tejun Heo
Hello, On Tue, Apr 16, 2024 at 04:20:10PM +0200, Michal Koutný wrote: > diff --git a/Documentation/admin-guide/cgroup-v2.rst > b/Documentation/admin-guide/cgroup-v2.rst > index 17e6e9565156..108b03dfb26a 100644 > --- a/Documentation/admin-guide/cgroup-v2.rst > +++

Re: [PATCH v4 1/6] cgroup/pids: Remove superfluous zeroing

2024-04-16 Thread Tejun Heo
On Tue, Apr 16, 2024 at 04:20:09PM +0200, Michal Koutný wrote: > 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ý Applied to cgroup/for-6.10.

Re: Re: [RFC PATCH v3 2/9] cgroup/pids: Separate semantics of pids.events related to pids.max

2024-04-12 Thread Tejun Heo
On Fri, Apr 12, 2024 at 04:23:24PM +0200, Michal Koutný wrote: > 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.) Oh, let's sepa

Re: [RFC PATCH v3 2/9] cgroup/pids: Separate semantics of pids.events related to pids.max

2024-04-08 Thread Tejun Heo
Hello, On Fri, Apr 05, 2024 at 07:05:41PM +0200, Michal Koutný wrote: > Currently, when pids.max limit is breached in the hierarchy, the event > is counted and reported in the cgroup where the forking task resides. > > This decouples the limit and the notification caused by the limit making > it

Re: [PATCH v2 0/2] cgroup/cpuset: Make cpuset hotplug processing synchronous

2024-04-08 Thread Tejun Heo
On Thu, Apr 04, 2024 at 09:47:47AM -0400, Waiman Long wrote: > v2: > - Found that rebuild_sched_domains() has external callers, revert its > change and introduce rebuild_sched_domains_cpuslocked() instead. > > As discussed in the LKML thread [1], the asynchronous nature of cpuset > hotplug

Re: [PATCH] selftests: cgroup: skip test_cgcore_lesser_ns_open when cgroup2 mounted without nsdelegate

2024-04-03 Thread Tejun Heo
On Wed, Mar 27, 2024 at 10:44:37AM +0800, Tianchen Ding wrote: > The test case test_cgcore_lesser_ns_open only tasks effect when cgroup2 > is mounted with "nsdelegate" mount option. If it misses this option, or > is remounted without "nsdelegate", the test case will fail. For example, > running

Re: [RFC PATCH bpf-next 0/3] bpf: freeze a task cgroup from bpf

2024-03-29 Thread Tejun Heo
Hello, On Fri, Mar 29, 2024 at 02:22:28PM +0100, Djalal Harouni wrote: > It would be easy at least for me if I just start with cgroupv2 and > ensure that it has same available filenames as if we go through kernfs. > Not a root cgroup node and maybe only freeze and kill for now that are > part of

Re: [RFC PATCH bpf-next 0/3] bpf: freeze a task cgroup from bpf

2024-03-28 Thread Tejun Heo
Hello, On Thu, Mar 28, 2024 at 02:28:51PM -0700, Alexei Starovoitov wrote: > > > So filename will be one of cgroup_base_files[].name ? > > > We probably don't want psi or cgroup1_base_files in there. > > > > Would it matter? > > Few weak reasons: > . cgroup_psi_files have show/write/poll/release

Re: [RFC PATCH bpf-next 0/3] bpf: freeze a task cgroup from bpf

2024-03-28 Thread Tejun Heo
Hello, On Thu, Mar 28, 2024 at 01:45:56PM -0700, Alexei Starovoitov wrote: > On Thu, Mar 28, 2024 at 1:02 PM Tejun Heo wrote: > > > > There's also cgroup.kill which would be useful for similar use cases. We can > > add interface for both but idk. Let's say w

Re: [RFC PATCH bpf-next 0/3] bpf: freeze a task cgroup from bpf

2024-03-28 Thread Tejun Heo
Hello, On Thu, Mar 28, 2024 at 12:46:03PM -0700, Alexei Starovoitov wrote: > To use kernel_file_open() it would need path, inode, cred. Yeah, it's more involved and potentially more controversial. That said, just to push the argument a bit further, at least for path, it'd be nice to have a

Re: [RFC PATCH bpf-next 0/3] bpf: freeze a task cgroup from bpf

2024-03-28 Thread Tejun Heo
Hello, Alexei. On Thu, Mar 28, 2024 at 10:32:24AM -0700, Alexei Starovoitov wrote: > > It bothers me a bit that it's adding a dedicated interface for something > > which already has a defined userspace interface. Would it be better to have > > kfunc wrappers for kernel_read() and kernel_write()?

Re: [RFC PATCH bpf-next 0/3] bpf: freeze a task cgroup from bpf

2024-03-28 Thread Tejun Heo
Hello, Djalal. On Wed, Mar 27, 2024 at 11:53:22PM +0100, Djalal Harouni wrote: > This patch series adds support to freeze the task cgroup hierarchy > that is on a default cgroup v2 without going through kernfs interface. > > For some cases we want to freeze the cgroup of a task based on some >

Re: [PATCH V3 bpf-next 1/2] bpf: add bpf_task_get_cgroup kfunc

2024-03-20 Thread Tejun Heo
, and cgroup_tryget to safely acquire a reference to it. > > Signed-off-by: Jose Fernandez > Reviewed-by: Tycho Andersen > Acked-by: Yonghong Song > Acked-by: Stanislav Fomichev Acked-by: Tejun Heo but some questions below > +__bpf_kfunc struct cgroup *bpf_task_ge

Re: [RFC PATCH 0/8] cgroup/cpuset: Support RCU_NOCB on isolated partitions

2024-01-17 Thread Tejun Heo
Hello, On Wed, Jan 17, 2024 at 11:35:03AM -0500, Waiman Long wrote: > The first 2 patches are adopted from Federic with minor twists to fix > merge conflicts and compilation issue. The rests are for implementing > the new cpuset.cpus.isolation_full interface which is essentially a flag > to

Re: [PATCH] cgroup/cpuset: Expose cpuset.cpus.isolated

2023-11-28 Thread Tejun Heo
Hello, On Mon, Nov 27, 2023 at 02:51:05PM -0500, Waiman Long wrote: > The root-only cpuset.cpus.isolated control file shows the current set > of isolated CPUs in isolated partitions. This control file is currently > exposed only with the cgroup_debug boot command line option which also > adds the

Re: [PATCH v4 0/5] cgroup/cpuset: Improve CPU isolation in isolated partitions

2023-11-19 Thread Tejun Heo
On Wed, Nov 15, 2023 at 10:34:00PM -0500, Waiman Long wrote: > v4: > - Update patch 1 to move apply_wqattrs_lock() and apply_wqattrs_unlock() >down into CONFIG_SYSFS block to avoid compilation warnings. I already applied v3 to cgroup/for-6.8. Can you please send the fix up patch against that

Re: [PATCH v2 0/4] cgroup/cpuset: Improve CPU isolation in isolated partitions

2023-11-12 Thread Tejun Heo
On Wed, Oct 25, 2023 at 02:25:51PM -0400, Waiman Long wrote: > v2: > - Add 2 read-only workqueue sysfs files to expose the user requested >cpumask as well as the isolated CPUs to be excluded from >wq_unbound_cpumask. > - Ensure that caller of the new workqueue_unbound_exclude_cpumask() >

Re: [PATCH v1] selftests: cgroup: Fixes a typo in a comment

2023-11-12 Thread Tejun Heo
On Mon, Nov 06, 2023 at 11:40:34PM +0530, Atul Kumar Pant wrote: > Signed-off-by: Atul Kumar Pant Applied to cgroup/for-6.8. Thanks. -- tejun

Re: [PATCH-cgroup 1/4] workqueue: Add workqueue_unbound_exclude_cpumask() to exclude CPUs from wq_unbound_cpumask

2023-10-23 Thread Tejun Heo
Hello, On Wed, Oct 18, 2023 at 03:18:52PM -0400, Waiman Long wrote: > I have a second thought after taking a further look at that. First of all, > cpuset_allowed_mask isn't relevant here and the mask can certainly contain > offline CPUs. So cpu_possible_mask is the proper fallback. > > With the

Re: [PATCH-cgroup 3/4] cgroup/cpuset: Keep track of CPUs in isolated partitions

2023-10-23 Thread Tejun Heo
Hello, Waiman. On Wed, Oct 18, 2023 at 02:24:00PM -0400, Waiman Long wrote: > If you mean saving the exclusion cpumask no matter who the caller is, we can > add another exclusion cpumask to save it and expose it to sysfs. This should > be done in the first workqueue patch, not as part of this

Re: [PATCH-cgroup 3/4] cgroup/cpuset: Keep track of CPUs in isolated partitions

2023-10-18 Thread Tejun Heo
On Wed, Oct 18, 2023 at 09:30:04AM -0400, Waiman Long wrote: > On 10/18/23 05:26, Tejun Heo wrote: > > On Fri, Oct 13, 2023 at 02:11:21PM -0400, Waiman Long wrote: > > ... > > > @@ -3875,6 +3931,13 @@ static struct cftype dfl_files[] = { > > >

Re: [PATCH-cgroup 3/4] cgroup/cpuset: Keep track of CPUs in isolated partitions

2023-10-18 Thread Tejun Heo
On Fri, Oct 13, 2023 at 02:11:21PM -0400, Waiman Long wrote: ... > @@ -3875,6 +3931,13 @@ static struct cftype dfl_files[] = { > .flags = CFTYPE_ONLY_ON_ROOT | CFTYPE_DEBUG, > }, > > + { > + .name = "cpus.isolated", > + .seq_show =

Re: [PATCH-cgroup 1/4] workqueue: Add workqueue_unbound_exclude_cpumask() to exclude CPUs from wq_unbound_cpumask

2023-10-18 Thread Tejun Heo
Hello, On Fri, Oct 13, 2023 at 02:11:19PM -0400, Waiman Long wrote: > When the "isolcpus" boot command line option is used to add a set > of isolated CPUs, those CPUs will be excluded automatically from > wq_unbound_cpumask to avoid running work functions from unbound > workqueues. > > Recently

Re: [PATCH-cgroup v2] cgroup/cpuset: Enable invalid to valid local partition transition

2023-10-04 Thread Tejun Heo
On Tue, Oct 03, 2023 at 10:44:20AM -0400, Waiman Long wrote: > When a local partition becomes invalid, it won't transition back to > valid partition automatically if a proper "cpuset.cpus.exclusive" or > "cpuset.cpus" change is made. Instead, system administrators have to > explicitly echo "root"