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 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
/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, 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" bail-out
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
signature
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 sgx_epc_misc_init(stru
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
> capac
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
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 creating
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 de
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
e 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
ind
fect 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
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 l
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 commi
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 change.
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 the
>
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 BUILD_BUG_ON(!(PID_MA
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 c
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 misc_cg_a
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 (READ_ONCE(misc_res_capacity[type
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 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
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 have
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 s
struct")
avoided the coarse use of mmap_sem in similar situations.
get_cmdline can also use arg_lock instead of mmap_sem when it reads the
boundaries.
Signed-off-by: Michal Koutný
---
mm/util.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/mm/util.c b/mm/util.c
index d
Hi.
I see this discussion somewhat faded away since the previous year.
There was rework [1] that reduced (ab)use of mmap_sem in prctl
functions.
Actually, there still remains the down_write() in prctl_set_mm.
I considered at least replacing it with the mm_struct.arg_lock +
down_read() but then I
On Wed, Apr 17, 2019 at 03:41:52PM +0200, Michal Hocko
wrote:
> Don't we need to use the lock in prctl_set_mm as well then?
Correct. The patch alone just moves the race from
get_cmdline/prctl_set_mm_map to get_cmdline/prctl_set_mm.
arg_lock could be used in prctl_set_mm but the better idea (IMO
On Wed, Apr 17, 2019 at 03:38:41PM +0300, Cyrill Gorcunov
wrote:
> I've a bit vague memory what we've ended up with, but iirc there was
> a problem with brk() syscall or similar. Then I think we left everything
> as is.
Was this related to the removal of non PR_SET_MM_MAP operations too?
Do you h
erforming basic
arguments validation.
Signed-off-by: Michal Koutný
---
kernel/sys.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/kernel/sys.c b/kernel/sys.c
index 12df0e5434b8..bbce0f26d707 100644
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -2125,8 +2125,1
in; charset=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
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
m
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
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
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 = cgroup_rstat_ini
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
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: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
s patch. See cgroup.c:
I stand corrected, the comment is still valid.
Therefore,
Reviewed-by: Michal Koutný
signature.asc
Description: Digital signature
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.
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 r
corner cases when
se->on_rq => 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(+),
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 c
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
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
--- a
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
count
the 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..3d629
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
> be
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,
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 t
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 ra
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
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
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
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 while
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, that
ur approach 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 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
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
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
>
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 (w
rocessor ugliness.
Reviewed-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
o better performance, 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
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 a
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.
(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)
>
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 rebind_subsystems
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 =
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
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 forma
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 wor
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 anymore
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
y 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
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 dat
On Mon, Jul 08, 2019 at 09:43:54AM +0100, Patrick Bellasi
wrote:
> Since it's possible for a cpu.uclamp.min value to be bigger than the
> cpu.uclamp.max value, ensure local consistency by restricting each
> "protection"
> (i.e. min utilization) with the corresponding "limit" (i.e. max
> utilizati
On Mon, Jul 08, 2019 at 09:43:55AM +0100, Patrick Bellasi
wrote:
> +static void uclamp_update_root_tg(void)
> +{
> + struct task_group *tg = &root_task_group;
> +
> + uclamp_se_set(&tg->uclamp_req[UCLAMP_MIN],
> + sysctl_sched_uclamp_util_min, false);
> + uclamp_se_s
On Mon, Jul 08, 2019 at 09:43:56AM +0100, Patrick Bellasi
wrote:
> This mimics what already happens for a task's CPU affinity mask when the
> task is also in a cpuset, i.e. cgroup attributes are always used to
> restrict per-task attributes.
If I am not mistaken when set_schedaffinity(2) call is
Hello Patrick.
I took a look at your series and I've posted some notes to your patches.
One applies more to the series overall -- I see there is enum uclamp_id
defined but at many places (local variables, function args) int or
unsigned int is used. Besides the inconsistency, I think it'd be nice
On Tue, Jul 16, 2019 at 03:07:06PM +0100, Patrick Bellasi
wrote:
> That note comes from the previous review cycle and it's based on a
> request from Tejun to align uclamp behaviors with the way the
> delegation model is supposed to work.
I saw and hopefully understood that reasoning -- uclamp.min
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 since
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 calls
Hello Song.
On Wed, Apr 10, 2019 at 07:43:35PM +, Song Liu
wrote:
> The load level above is measured as requests-per-second.
>
> When there is no side workload, the system has about 45% busy CPU with
> load level of 1.0; and about 75% busy CPU at load level of 1.5.
>
> The saturation st
On Tue, Apr 09, 2019 at 04:40:03PM -0400, Joel Savitz
wrote:
> $ grep Cpus /proc/$$/status
> Cpus_allowed: ff
> Cpus_allowed_list: 0-7
(a)
> $ taskset -p 4 $$
> pid 19202's current affinity mask: f
> pid 19202's new affinity mask: 4
>
> $ grep
Hi,
making this holder of mmap_sem killable was for the reasons of /proc/...
diagnostics was an idea I was pondeering too. However, I think the
approach of pretending we read 0 bytes is not correct. The API would IMO
need to be extended to allow pass a result such as EINTR to the end
caller.
Why do
Hello.
(apologies for late reply) I've aggregated the two previously discussed patches
into one series and based on responses made some changes summed below.
v2
- insert a patch refactoring validate_prctl_map
- move find_vma out of the arg_lock critical section
Michal Koutný (3):
struct")
avoided the coarse use of mmap_sem in similar situations.
get_cmdline can also use arg_lock instead of mmap_sem when it reads the
boundaries.
Fixes: 88aa7cc688d4 ("mm: introduce arg_lock to protect arg_start|end and
env_start|end in mm_struct")
Cc: Yang Shi
Cc: Mateusz
v2: call find_vma without arg_lock held
CC: Cyrill Gorcunov
CC: Laurent Dufour
Signed-off-by: Michal Koutný
---
kernel/sys.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/kernel/sys.c b/kernel/sys.c
index e1acb444d7b0..641fda756575 100644
--- a/kernel/sys.c
++
tch should not change any behavior, it is mere refactoring for
following patch.
CC: Kirill Tkhai
CC: Cyrill Gorcunov
Signed-off-by: Michal Koutný
---
kernel/sys.c | 45 -
1 file changed, 20 insertions(+), 25 deletions(-)
diff --git a/kernel/sys.c b/ke
On Tue, Apr 30, 2019 at 01:45:17PM +0300, Cyrill Gorcunov
wrote:
> It setups these parameters unconditionally. I need to revisit
> this moment. Technically (if only I'm not missing something
> obvious) we might have a race here with prctl setting up new
> params, but this should be harmless since
rt|end in mm_struct")
Cc: Yang Shi
Cc: Mateusz Guzik
CC: Cyrill Gorcunov
Co-developed-by: Laurent Dufour
Signed-off-by: Laurent Dufour
Signed-off-by: Michal Koutný
---
kernel/sys.c | 10 --
mm/util.c| 4 ++--
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git
tch should not change any behavior, it is mere refactoring for
following patch.
v1, v2: ---
v3: Remove unused mm variable from validate_prctl_map_addr
CC: Kirill Tkhai
CC: Cyrill Gorcunov
Signed-off-by: Michal Koutný
Reviewed-by: Kirill Tkhai
---
kernel/
unused variable mm
Michal Koutný (2):
prctl_set_mm: Refactor checks from validate_prctl_map
prctl_set_mm: downgrade mmap_sem to read lock
kernel/sys.c | 56
mm/util.c| 4 ++--
2 files changed, 30 insertions(+), 30 deletions
Hello Yun.
On Fri, Jul 12, 2019 at 06:10:24PM +0800, 王贇
wrote:
> Forgive me but I have no idea on how to combined this
> with memory cgroup's locality hierarchical update...
> parent memory cgroup do not have influence on mems_allowed
> to it's children, correct?
I'd recommend to look at the v2
1 - 100 of 137 matches
Mail list logo
