On Tue, Apr 09, 2024 at 11:01:26AM GMT, Steven Rostedt
wrote:
> > - tpid = pid & (PID_MAX_DEFAULT - 1);
> > + tpid = pid % PID_MAP_SIZE;
>
> Does that compile to the same? This is a fast path.
I didn't check.
If fast is the intetion, I would change it to something
like
On Mon, Apr 08, 2024 at 04:58:18PM GMT, Michal Koutný wrote:
> The kernel provides mechanisms, while it should not imply policies --
> default pid_max seems to be an example of the policy that does not fit
> all. At the same time pid_max must have some value assigned, so use
On Thu, Apr 11, 2024 at 03:03:31PM -0700, Andrew Morton
wrote:
> A large increase in the maximum number of processes.
The change from (some) default to effective infinity is the crux of the
change. Because that is only a number.
(Thus I don't find the number's 12700% increase alone a big
Hello.
On Mon, Apr 08, 2024 at 01:29:55PM -0700, Andrew Morton
wrote:
> That seems like a large change.
In what sense is it large?
I tried to lookup the code parts that depend on this default and either
add the other patches or mention the impact (that part could be more
thorough) in the
On Mon, Apr 08, 2024 at 11:23:21PM -0500, Haitao Huang
wrote:
> It's always non-NULL based on testing.
>
> It's hard for me to say definitely by reading the code. But IIUC
> cgroup_disable command-line only blocks operations in /sys/fs/cgroup so user
> space can't set up controllers and config
ct on size of structure that alloc_pid/idr_alloc_cyclic
eventually uses and structure that kernel tracing uses with
'record-tgid' (~16 MiB).
Signed-off-by: Michal Koutný
---
include/linux/pid.h | 4 ++--
include/linux/threads.h | 15 ---
kernel/pid.c| 8 +++-
3 fil
The point of this exercise is to remove dependency on PID_MAX_DEFAULT.
Signed-off-by: Michal Koutný
---
kernel/trace/trace_sched_switch.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/kernel/trace/trace_sched_switch.c
b/kernel/trace/trace_sched_switch.c
index 8a
defined MAX_PID.
Should PID_MAX_LIMIT change in future or pid_max escapes PID_MAX_LIMIT,
appropriate checks remain in place. No functional change intended.
Signed-off-by: Michal Koutný
---
kernel/trace/pid_list.c | 6 +++---
kernel/trace/pid_list.h | 4 ++--
2 files changed, 5 insertions(+), 5
range -- pid_max_max.
More details are in that commit's message. The other two commits are
related preparation and less related refresh in code that somewhat
references pid_max.
Michal Koutný (3):
tracing: Remove dependency of saved_cmdlines_buffer on PID_MAX_DEFAULT
kernel/pid: Remove default
On Tue, Apr 02, 2024 at 11:20:21AM -0500, Haitao Huang
wrote:
> Do we really want to have it implemented in c?
I only pointed to the available C boilerplate.
> There are much fewer lines of
> code in shell scripts. Note we are not really testing basic cgroup stuff.
> All we needed were
Hello.
On Sat, Mar 30, 2024 at 01:26:08PM +0200, Jarkko Sakkinen
wrote:
> > > It'd be more complicated and less readable to do all the stuff without
> > > the
> > > cgroup-tools, esp cgexec. I checked dependency, cgroup-tools only depends
> > >
> > > on libc so I hope this would not cause
Hello.
On Mon, Feb 26, 2024 at 03:48:18PM -0600, Haitao Huang
wrote:
> In case of overcomitting, i.e., sum of limits greater than the EPC capacity,
> if one group has a fault, and its usage is not above its own limit
> (try_charge() passes), yet total usage of the system has exceeded the
>
On Mon, Feb 05, 2024 at 01:06:27PM -0800, Haitao Huang
wrote:
> +static int sgx_epc_cgroup_alloc(struct misc_cg *cg);
> +
> +const struct misc_res_ops sgx_epc_cgroup_ops = {
> + .alloc = sgx_epc_cgroup_alloc,
> + .free = sgx_epc_cgroup_free,
> +};
> +
> +static void
On Tue, Feb 20, 2024 at 09:52:39AM +, "Huang, Kai"
wrote:
> I am not sure, but is it possible or legal for an ancestor to have less limit
> than children?
Why not?
It is desired for proper hiearchical delegation and the tightest limit
of ancestors applies (cf memory.max).
Michal
On Mon, Jan 29, 2024 at 04:18:36PM +0530, Deepak Kumar Singh
wrote:
> There is already a patch posted for similar problem -
> https://lore.kernel.org/all/20231201110631.669085-1-quic_dee...@quicinc.com/
I was not aware, thanks for the pointer.
Do you plan to update your patch to "just"
/32d9c3a2f2b6a4d1fc48d6871194f3faf3184e8b
Suggested-by: Chris Lew
Suggested-by: Sarannya S
Signed-off-by: Michal Koutný
---
drivers/rpmsg/qcom_glink_smem.c | 9 +
1 file changed, 9 insertions(+)
Why RFC? The patch is adopted from the link above. It would be good to
asses whether such conditions can also happen
On Mon, Oct 30, 2023 at 11:20:02AM -0700, Haitao Huang
wrote:
> From: Kristen Carlson Accardi
>
> The misc cgroup controller (subsystem) currently does not perform
> resource type specific action for Cgroups Subsystem State (CSS) events:
> the 'css_alloc' event when a cgroup is created and the
Hello.
On Mon, Dec 18, 2023 at 03:24:40PM -0600, Haitao Huang
wrote:
> Thanks for raising this. Actually my understanding the above discussion was
> mainly about not doing reclaiming by killing enclaves, i.e., I assumed
> "reclaiming" within that context only meant for that particular kind.
>
On Wed, Oct 18, 2023 at 08:37:25AM -0700, Dave Hansen
wrote:
> 1. Admin sets a limit
> 2. Enclave is created
> 3. Enclave hits limit, allocation fails
I was actually about to suggest reorganizing the series to a part
implementing this simple limiting and a subsequent part with the reclaim
stuff
On Tue, Oct 17, 2023 at 08:54:48PM +0200, Michal Koutný
wrote:
> Is this distinction between preemptability of EPC pages mandated by the
> HW implementation? (host/"process" enclaves vs VM enclaves) Or do have
> users an option to lock certain pages in memory that yield
On Fri, Sep 22, 2023 at 08:06:40PM -0700, Haitao Huang
wrote:
> @@ -276,10 +276,13 @@ static ssize_t misc_cg_max_write(struct
> kernfs_open_file *of, char *buf,
>
> cg = css_misc(of_css(of));
>
> - if (READ_ONCE(misc_res_capacity[type]))
> + if
On Fri, Sep 22, 2023 at 08:06:55PM -0700, Haitao Huang
wrote:
> +static void sgx_epc_cgroup_free(struct misc_cg *cg)
> +{
> + struct sgx_epc_cgroup *epc_cg;
> +
> + epc_cg = sgx_epc_cgroup_from_misc_cg(cg);
It should check for !epc_cg since the misc controller implementation
in
Hello Haitao.
On Tue, Oct 17, 2023 at 07:58:02AM -0500, Haitao Huang
wrote:
> AFAIK, before we introducing max_write() callback in this series, no misc
> controller would possibly enforce the limit when misc.max is reduced. e.g. I
> don't think CVMs be killed when ASID limit is reduced and the
On Wed, Apr 07, 2021 at 08:34:24PM +0200, Peter Zijlstra
wrote:
> IMO as long as cgroups have that tasks file, you get to support people
> using it. That means that tasks joining your cgroup need to 'inherit'
> cgroup properties.
The tasks file is consequence of binding this to cgroups, I'm one
Hello.
IIUC, the premise is that the tasks that have different cookies imply
they would never share a core.
On Thu, Apr 01, 2021 at 03:10:12PM +0200, Peter Zijlstra wrote:
> The cgroup interface now uses a 'core_sched' file, which still takes 0,1. It
> is
> however changed such that you can
On Tue, Mar 30, 2021 at 11:00:36AM +0200, Arnd Bergmann wrote:
> Would it be possible to enclose most or all of kernel/cgroup/cgroup.c
> in an #ifdef CGROUP_SUBSYS_COUNT block?
Even without any controllers, there can still be named hierarchies (v1)
or the default hierarchy (v2) (for instance) for
viewed-by: Michal Koutný
signature.asc
Description: Digital signature
On Mon, Mar 15, 2021 at 07:41:00PM -0400, Johannes Weiner
wrote:
> Switch to the atomic variant, cgroup_rstat_irqsafe().
Congratulations(?), the first use of cgroup_rstat_irqsafe().
Reviewed-by: Michal Koutný
signature.asc
Description: Digital signature
On Fri, Mar 12, 2021 at 09:49:26AM -0800, Vipin Sharma
wrote:
> I will add some more information in the cover letter of the next version.
Thanks.
> Each one coming up with their own interaction is a duplicate effort
> when they all need similar thing.
Could this be expressed as a new BPF hook
On Fri, Mar 12, 2021 at 11:07:14AM -0800, Vipin Sharma
wrote:
> We should be fine without atomic64_t because we are using unsigned
> long and not 64 bit explicitly. This will work on both 32 and 64 bit
> machines.
I see.
> But I will add READ_ONCE and WRITE_ONCE because of potential chances of
Hi Vipin.
On Thu, Mar 04, 2021 at 03:19:45PM -0800, Vipin Sharma
wrote:
> arch/x86/kvm/svm/sev.c| 65 +-
> arch/x86/kvm/svm/svm.h| 1 +
> include/linux/cgroup_subsys.h | 4 +
> include/linux/misc_cgroup.h | 130 +++
> init/Kconfig | 14 ++
>
Hello.
On Sun, Mar 07, 2021 at 07:48:40AM -0500, Tejun Heo wrote:
> Vipin, thank you very much for your persistence and patience.
Yes, and thanks for taking my remarks into account.
> Michal, as you've been reviewing the series, can you please take
> another look and ack them if you don't find
Hello.
(Sorry for necroposting, found this upstream reference only now.)
On Mon, Apr 20, 2020 at 03:04:53PM +0800, Muchun Song
wrote:
> /* Time spent by the tasks of the CPU accounting group executing in ... */
> @@ -339,7 +340,7 @@ void cpuacct_charge(struct task_struct *tsk, u64 cputime)
>
On Thu, Feb 25, 2021 at 11:28:46AM -0800, Vipin Sharma
wrote:
> My approach here is that it is the responsibility of the caller to:
> 1. Check the return value and proceed accordingly.
> 2. Ideally, let all of the usage be 0 before deactivating this resource
>by setting capacity to 0
If the
gt; cfs_rq_of(se)->on_list wouldn't hold, so the patch
certainly isn't finished.
Signed-off-by: Michal Koutný
---
kernel/sched/fair.c | 41 ++---
kernel/sched/sched.h | 4 +---
2 files changed, 7 insertions(+), 38 deletions(-)
diff --git a/kernel/sched/fa
On Wed, Feb 24, 2021 at 08:57:36PM -0800, Vipin Sharma
wrote:
> This function is meant for hot unplug functionality too.
Then I'm wondering if the current form is sufficient, i.e. the generic
controller can hardly implement preemption but possibly it should
prevent any additional charges of the
On Tue, Feb 23, 2021 at 05:24:23PM +0800, Muchun Song
wrote:
> mm/slab_common.c | 4 ++--
> mm/slub.c| 8
> 2 files changed, 6 insertions(+), 6 deletions(-)
Reviewed-by: Michal Koutný
signature.asc
Description: Digital signature
On Thu, Feb 18, 2021 at 11:55:48AM -0800, Vipin Sharma
wrote:
> --- a/arch/x86/kvm/svm/sev.c
> +++ b/arch/x86/kvm/svm/sev.c
> [...]
> +#ifndef CONFIG_KVM_AMD_SEV
> +/*
> + * When this config is not defined, SEV feature is not supported and APIs in
> + * this file are not used but this file still
Hello.
On Thu, Feb 18, 2021 at 11:55:47AM -0800, Vipin Sharma
wrote:
> This patch is creating a new misc cgroup controller for allocation and
> tracking of resources which are not abstract like other cgroup
> controllers.
Please don't refer to this as "allocation" anywhere, that has a specific
t=UTF-8
Content-Transfer-Encoding: 8bit
The function has no current users and it is a remnant from kdbus
enthusiasm era 857a2beb09ab ("cgroup: implement
task_cgroup_path_from_hierarchy()"). Drop it to eliminate unused code.
Suggested-by: Romain Perier
Signed-off-by: Michal Koutný
---
in
stats cpu time updates.) This is
just for reference, to stress the current rstat design.
> ---
> include/linux/memcontrol.h | 67 ++-
> mm/memcontrol.c| 223 +++--
> 2 files changed, 132 insertions(+), 158 deletions(-)
Well done.
stand corrected, the comment is still valid.
Therefore,
Reviewed-by: Michal Koutný
signature.asc
Description: Digital signature
On Tue, Feb 09, 2021 at 11:33:04AM -0500, Johannes Weiner
wrote:
> ---
> tools/testing/selftests/cgroup/test_kmem.c | 22 ++
> 1 file changed, 14 insertions(+), 8 deletions(-)
Reviewed-by: Michal Koutný
signature.asc
Description: Digital signature
On Tue, Feb 09, 2021 at 11:32:58AM -0500, Johannes Weiner
wrote:
> include/linux/memcontrol.h | 8 +---
> mm/memcontrol.c| 21 +++--
> 2 files changed, 12 insertions(+), 17 deletions(-)
Reviewed-by: Michal Koutný
signature.asc
Description: Digital signature
On Tue, Feb 09, 2021 at 11:32:59AM -0500, Johannes Weiner
wrote:
> include/linux/memcontrol.h | 44 --
> mm/memcontrol.c| 32 +++
> 2 files changed, 32 insertions(+), 44 deletions(-)
Reviewed-by: Mich
On Tue, Feb 09, 2021 at 11:32:57AM -0500, Johannes Weiner
wrote:
> mm/memcontrol.c | 35 +--
> 1 file changed, 21 insertions(+), 14 deletions(-)
Reviewed-by: Michal Koutný
signature.asc
Description: Digital signature
Hello.
On Tue, Feb 09, 2021 at 11:33:00AM -0500, Johannes Weiner
wrote:
> @@ -1971,10 +1978,14 @@ int cgroup_setup_root(struct cgroup_root *root, u16
> ss_mask)
> if (ret)
> goto destroy_root;
>
> - ret = rebind_subsystems(root, ss_mask);
> + ret =
then the
switch probably doesn't happen at this moment (and I guess
stock->cached_objcg and stock->cached can be independent to some extent,
so the old memcg in one needn't be the old in the latter).
In conclusion
Reviewed-by: Michal Koutný
Michal
signature.asc
Description: Digital signature
On Fri, Jan 15, 2021 at 05:37:17PM +0800, Chen Zhou
wrote:
> [...]
> kernel/cgroup/cgroup-v1.c | 3 +++
> 1 file changed, 3 insertions(+)
Reviewed-by: Michal Koutný
signature.asc
Description: Digital signature
h correct
Reviewed-by: Michal Koutný
> The behavior was changed since commit f5dfb5315d34 ("cgroup: take
> options parsing into ->parse_monolithic()"), will add this as Fixes.
Thanks.
Michal
signature.asc
Description: Digital signature
On Thu, Jan 14, 2021 at 10:08:19PM +0800, chenzhou
wrote:
> In this case, at the beginning of function check_cgroupfs_options(), the mask
> ctx->subsys_mask will be 0. And if we mount without 'none' and 'name='
> options,
> then in check_cgroupfs_options(), the flag ctx->all_ss will be set,
Hello Chen.
On Fri, Dec 18, 2020 at 02:17:55PM +0800, Chen Zhou
wrote:
> When mounting a cgroup hierarchy with disabled controller in cgroup v1,
> all available controllers will be attached.
Not sure if I understand the situation -- have you observed a v1
controller attached to a hierarchy
re almost
identical. In order to reduce duplication, factor out the common code in
similar fashion we already do for other threadgroup/task functions. No
functional changes are intended.
Suggested-by: Hao Lee
Signed-off-by: Michal Koutný
---
kernel/cgroup/cgro
es - high,
> + GFP_KERNEL, true);
Although I was also initially confused by throwing 'reclaimed' info
away, the patch makes sense to me given the reasoning.
It is
Reviewed-by: Michal Koutný
As for the discussed unsuccessful retries, I'd keep it a separate chan
Hi.
On Tue, Nov 10, 2020 at 07:11:28AM -0800, Shakeel Butt
wrote:
> > The problem is that cgroup_subsys_on_dfl(memory_cgrp_subsys)'s return value
> > can change at any particular moment.
The switch can happen only when singular (i.e. root-only) hierarchy
exists. (Or it could if
sn't affect how the hierarchical mode is working,
> which is the only sane and truly supported mode now.
I agree with the patch and you can add
Reviewed-by: Michal Koutný
However, it effectively switches any users of root.use_hierarchy=0 (if there
are any, watching the coun
Hi.
On Tue, Oct 20, 2020 at 06:52:08AM +0100, Richard Palethorpe
wrote:
> I don't think that is relevant as we get the memcg from objcg->memcg
> which is set during reparenting. I suppose however, we can determine if
> the objcg was reparented by inspecting memcg->objcg.
+1
> If we just check
Hi.
On Mon, Oct 19, 2020 at 03:28:45PM -0700, Roman Gushchin wrote:
> Currently the root memory cgroup is never charged directly, but
> if an ancestor cgroup is charged, the charge is propagated up to the
s/ancestor/descendant/
> The root memory cgroup doesn't show the charge to a user, neither
On Fri, Oct 16, 2020 at 04:05:21PM +0100, Richard Palethorpe
wrote:
> I'm don't know if that could happen without reparenting. I suppose if
> use_hierarchy=1 then actually this patch will result in root being
> overcharged, so perhaps it should also check for use_hierarchy?
Right, you'd need to
On Fri, Oct 16, 2020 at 10:53:08AM -0400, Johannes Weiner
wrote:
> The central try_charge() function charges recursively all the way up
> to and including the root.
Except for use_hiearchy=0 (which is the case here as Richard
wrote). The reparenting is hence somewhat incompatible with
Hello.
On Wed, Oct 14, 2020 at 08:07:49PM +0100, Richard Palethorpe
wrote:
> SLAB objects which outlive their memcg are moved to their parent
> memcg where they may be uncharged. However if they are moved to the
> root memcg, uncharging will result in negative page counter values as
> root has
On Thu, Oct 01, 2020 at 01:27:13PM -0400, Johannes Weiner
wrote:
> The activation code is the only path where page migration is not
> excluded. Because unlike with page state statistics, we don't really
> mind a race when counting an activation event.
Thanks for the explanation. I see why the
Hi.
On Wed, Sep 30, 2020 at 05:27:10PM -0700, Roman Gushchin wrote:
> @@ -369,8 +371,12 @@ enum page_memcg_data_flags {
> */
> static inline struct mem_cgroup *page_memcg(struct page *page)
> {
> + unsigned long memcg_data = page->memcg_data;
> +
> VM_BUG_ON_PAGE(PageSlab(page),
On Tue, Aug 11, 2020 at 12:32:28PM -0700, Roman Gushchin wrote:
> If we'll limit init.slice (where systemd seems to reside), as you suggest,
> we'll eventually create trashing in init.slice, followed by OOM.
> I struggle to see how it makes the life of a user better?
> [...]
> The problem is that
On Tue, Aug 11, 2020 at 09:55:27AM -0700, Roman Gushchin wrote:
> As I said, there are 2 problems with charging systemd (or a similar daemon):
> 1) It often belongs to the root cgroup.
This doesn't hold for systemd (if we agree that systemd is the most
common case).
> 2) OOMing or failing some
Hi Shakeel.
On Tue, Jul 07, 2020 at 10:02:50AM -0700, Shakeel Butt
wrote:
> > Well, I was talkingg about memory.low. It is not meant only to protect
> > from the global reclaim. It can be used for balancing memory reclaim
> > from _any_ external memory pressure source. So it is somehow related
On Thu, Aug 06, 2020 at 09:37:17PM -0700, Roman Gushchin wrote:
> In general, yes. But in this case I think it wouldn't be a good idea:
> most often cgroups are created by a centralized daemon (systemd),
> which is usually located in the root cgroup. Even if it's located not in
> the root cgroup,
Hello.
On Tue, Jun 23, 2020 at 11:45:14AM -0700, Roman Gushchin wrote:
> Because the size of memory cgroup internal structures can dramatically
> exceed the size of object or page which is pinning it in the memory, it's
> not a good idea to simple ignore it. It actually breaks the isolation
>
inner-node constraint may be added later.)
Signed-off-by: Michal Koutný
---
Documentation/admin-guide/cgroup-v2.rst | 3 ---
1 file changed, 3 deletions(-)
diff --git a/Documentation/admin-guide/cgroup-v2.rst
b/Documentation/admin-guide/cgroup-v2.rst
index 47f9f056e66f..3d62922c4
patch just makes docs indefinite until the idea is implemented.
Michal Koutný (3):
docs: cgroup: Explain reclaim protection target
docs: cgroup: Note about sibling relative reclaim protection
docs: cgroup: No special handling of unpopulated memcgs
Documentation/admin-guide/cgroup-v
Signed-off-by: Michal Koutný
---
Documentation/admin-guide/cgroup-v2.rst | 24 +---
1 file changed, 21 insertions(+), 3 deletions(-)
diff --git a/Documentation/admin-guide/cgroup-v2.rst
b/Documentation/admin-guide/cgroup-v2.rst
index d09471aa7443..94bdff4f9e09 100644
Signed-off-by: Michal Koutný
---
Documentation/admin-guide/cgroup-v2.rst | 4
1 file changed, 4 insertions(+)
diff --git a/Documentation/admin-guide/cgroup-v2.rst
b/Documentation/admin-guide/cgroup-v2.rst
index 94bdff4f9e09..47f9f056e66f 100644
--- a/Documentation/admin-guide/cgroup-v2
nification is also aligning FilePmdMapped with others.)
Signed-off-by: Michal Koutný
---
fs/proc/task_mmu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index dbda4499a859..5066b0251ed8 100644
--- a/fs/proc/task_mmu.c
+++
On Wed, Jun 24, 2020 at 01:54:56PM +0200, Christian Brauner
wrote:
> Yep, I already have a fix for this in my tree based on a previous
> report from LTP.
Perfect. (Sorry for the noise then.)
Thanks,
Michal
signature.asc
Description: Digital signature
Hi.
On Tue, May 05, 2020 at 04:04:31PM +0200, Christian Brauner
wrote:
> -SYSCALL_DEFINE2(setns, int, fd, int, nstype)
> +SYSCALL_DEFINE2(setns, int, fd, int, flags)
> [...]
> - file = proc_ns_fget(fd);
> - if (IS_ERR(file))
> - return PTR_ERR(file);
> + int err = 0;
>
Hello.
I see suspicious asymmetry, in the current mainline:
> WRITE_ONCE(memcg->memory.emin, effective_protection(usage, parent_usage,
> READ_ONCE(memcg->memory.min),
> READ_ONCE(parent->memory.emin),
>
On Fri, Oct 04, 2019 at 03:11:04PM -0700, Roman Gushchin wrote:
> An inode which is getting dirty for the first time is associated
> with the wb structure (look at __inode_attach_wb()). It can later
> be switched to another wb under some conditions (e.g. some other
> cgroup is writing a lot of
Simplify task migration by being oblivious about its PID during
migration. This allows to easily migrate individual threads as well.
This change brings no functional change and prepares grounds for thread
granularity migrating tests.
Signed-off-by: Michal Koutný
---
tools/testing/selftests
Add two new tests that verify that thread and threadgroup migrations
work as expected.
Signed-off-by: Michal Koutný
---
tools/testing/selftests/cgroup/Makefile | 2 +-
tools/testing/selftests/cgroup/cgroup_util.c | 26
tools/testing/selftests/cgroup/cgroup_util.h | 2 +
tools
test_core tests various cgroup creation/removal and task migration
paths. Run the tests repeatedly with interfering noise (for lockdep
checks). Currently, forking noise and subsystem enabled/disabled
switching are the implemented noises.
Signed-off-by: Michal Koutný
---
tools/testing/selftests
We no longer take cgroup_mutex in cgroup_exit and the exiting tasks are
not moved to init_css_set, reflect that in several comments to prevent
confusion.
Signed-off-by: Michal Koutný
---
kernel/cgroup/cgroup.c | 29 +
1 file changed, 9 insertions(+), 20 deletions
Hello.
The important part is the patch 02 where the reasoning is.
The rest is mostly auxiliar and split out into separate commits for
better readability.
The patches are based on v5.3.
Michal
Michal Koutný (5):
cgroup: Update comments about task exit path
cgroup: Optimize single thread
only the case of self-migration by writing "0" into
cgroup.threads. For simplicity, we always take cgroup_threadgroup_rwsem
with numeric PIDs.
This change improves migration dependent workload performance similar
to per-signal_struct state.
Signed-off-by: Michal Koutný
---
kernel/cgroup
Hi (and apology for relatively late reply).
On Tue, Sep 10, 2019 at 09:08:55AM -0700, Tejun Heo wrote:
> I can implement the switching if so.
I see the "conflict" is solved by the switching.
> Initially, I put them under block device sysfs but it was too clumsy
> with different config file
On Wed, Oct 02, 2019 at 10:00:07PM +0900, Suleiman Souhlal
wrote:
> kmem.slabinfo has been absolutely invaluable for debugging, in my experience.
> I am however not aware of any automation based on it.
My experience is the same. However, the point is that this has been
exposed since ages, so the
On Thu, Sep 05, 2019 at 02:45:44PM -0700, Roman Gushchin wrote:
> Roman Gushchin (14):
> [...]
> mm: memcg/slab: use one set of kmem_caches for all memory cgroups
From that commit's message:
> 6) obsoletes kmem.slabinfo cgroup v1 interface file, as there are
> no per-memcg kmem_caches
Hi.
On Thu, Sep 26, 2019 at 05:55:29PM -0700, Mina Almasry
wrote:
> My guess is that a new controller needs to support cgroups-v2, which
> is fine. But can a new controller also support v1? Or is there a
> requirement that new controllers support *only* v2? I need whatever
> solution here to
On Mon, Sep 02, 2019 at 04:02:57PM -0700, Suren Baghdasaryan
wrote:
> > +static inline void cpu_uclamp_print(struct seq_file *sf,
> > + enum uclamp_id clamp_id)
> > [...]
> > + rcu_read_lock();
> > + tg = css_tg(seq_css(sf));
> > + util_clamp =
(+CC cgro...@vger.kernel.org)
On Thu, Aug 08, 2019 at 12:40:02PM -0700, Mina Almasry
wrote:
> We have developers interested in using hugetlb_cgroups, and they have
> expressed
> dissatisfaction regarding this behavior.
I assume you still want to enforce a limit on a particular group and the
On Thu, Aug 08, 2019 at 04:10:21PM +0100, Patrick Bellasi
wrote:
> Not sure to get what you mean here: I'm currently exposing uclamp to
> both v1 and v2 hierarchies.
cpu controller has different API for v1 and v2 hierarchies. My question
reworded is -- are the new knobs exposed in the legacy API
On Thu, Aug 08, 2019 at 04:08:10PM +0100, Patrick Bellasi
wrote:
> Well, if I've got correctly your comment in the previous message, I
> would say that at this stage we don't need RCU looks at all.
Agreed.
> Reason being that cpu_util_update_eff() gets called only from
> cpu_uclamp_write()
On Fri, Aug 02, 2019 at 10:08:47AM +0100, Patrick Bellasi
wrote:
> Patrick Bellasi (6):
> sched/core: uclamp: Extend CPU's cgroup controller
> sched/core: uclamp: Propagate parent clamps
> sched/core: uclamp: Propagate system defaults to root group
> sched/core: uclamp: Use TG's clamps
On Fri, Aug 02, 2019 at 10:08:49AM +0100, Patrick Bellasi
wrote:
> @@ -7095,6 +7149,7 @@ static ssize_t cpu_uclamp_write(struct kernfs_open_file
> *of, char *buf,
> if (req.ret)
> return req.ret;
>
> + mutex_lock(_mutex);
> rcu_read_lock();
>
> tg =
On Fri, Aug 02, 2019 at 10:08:48AM +0100, Patrick Bellasi
wrote:
> +static ssize_t cpu_uclamp_write(struct kernfs_open_file *of, char *buf,
> + size_t nbytes, loff_t off,
> + enum uclamp_id clamp_id)
> +{
> + struct uclamp_request req;
On Thu, Jul 18, 2019 at 07:17:45PM +0100, Patrick Bellasi
wrote:
> The clamp values are not tunable at the level of the root task group.
> That's for two main reasons:
>
> - the root group represents "system resources" which are always
>entirely available from the cgroup standpoint.
>
>
On Thu, Jul 18, 2019 at 07:17:43PM +0100, Patrick Bellasi
wrote:
> +static ssize_t cpu_uclamp_min_write(struct kernfs_open_file *of,
> + char *buf, size_t nbytes,
> + loff_t off)
> +{
> [...]
> +static ssize_t
On Tue, Jul 16, 2019 at 10:41:36AM +0800, 王贇
wrote:
> Actually whatever the memory node sets or cpu allow sets is, it will
> take effect on task's behavior regarding memory location and cpu
> location, while the locality only care about the results rather than
> the sets.
My previous response
On Tue, Jul 16, 2019 at 11:40:35AM +0800, 王贇
wrote:
> By doing 'cat /sys/fs/cgroup/cpu/CGROUP_PATH/cpu.numa_stat', we see new
> output line heading with 'exectime', like:
>
> exectime 311900 407166
What you present are times aggregated over CPUs in the NUMA nodes, this
seems a bit lossy
On Tue, Jul 16, 2019 at 03:34:35PM +0100, Patrick Bellasi
wrote:
> Am I missing something?
No, it's rather my misinterpretation of the syscall semantics.
> Otherwise, I think the changelog sentence you quoted is just
> misleading.
It certainly mislead me to thinking about the sched_setattr
On Tue, Jul 16, 2019 at 03:34:17PM +0100, Patrick Bellasi
wrote:
> > cpu_util_update_eff internally calls css_for_each_descendant_pre() so
> > this should be protected with rcu_read_lock().
>
> Right, good catch! Will add in v12.
When I responded to your other patch, it occurred to me that
1 - 100 of 131 matches
Mail list logo
