Joel Fernandes (Google)
Acked-by: Tejun Heo
> #define for_each_pwq(pwq, wq)
> \
> - list_for_each_entry_rcu((pwq), &(wq)->pwqs, pwqs_node) \
> - if (({ assert_rcu_or_wq_mutex(wq); false; })
On Thu, May 30, 2019 at 12:24:25AM +0200, Odin Ugedal wrote:
> Add another example to clarify that HugePages smaller than 1MB will
> be displayed using "KB", with an uppercased K (eg. 20KB), and not the
> normal SI prefix kilo (small k).
>
> Because of a misunderstanding/copy-paste error inside ru
On Sat, Feb 09, 2019 at 04:05:33PM +0100, Tibor Billes wrote:
> cgroup: add documentation for pids.events file
>
> Document the event counters file for pid cgroups.
>
> Signed-off-by: Tibor Billes
Applied to cgroup/for-5.0.
Thanks.
--
tejun
de/cgroup-v2.rst:1511: WARNING: Block quote ends
> without a blank line; unexpected unindent.
> Documentation/admin-guide/cgroup-v2.rst:1512: WARNING: Block quote ends
> without a blank line; unexpected unindent.
>
> Signed-off-by: Randy Dunlap
> Cc: Tejun Heo
> Cc: L
Hello, Paolo.
On Sun, Dec 30, 2018 at 11:25:25AM +0100, Paolo Valente wrote:
> What's the benefit of throwing away months of work, on which we agreed
> before starting it, and that solves a problem already acknowledged by
> interested parties?
Showing multiple conflicting numbers definitely isn't
On Sun, Dec 30, 2018 at 05:50:44PM +0100, Otto Sabart wrote:
> Improve readability using the :file: markup.
Heh, that's a minor plus for formatted output and minor minus for the
source. If this is a convention generally followed for
documentations, I have no objects. That said, can you please re
On Sun, Dec 30, 2018 at 08:01:55PM +0100, Otto Sabart wrote:
> This patch fixes multiple build warnings:
> "WARNING: Block quote ends without a blank line; unexpected unindent."
>
> Signed-off-by: Otto Sabart
Applied to cgroup/for-4.22.
Thanks.
--
tejun
On Sun, Dec 30, 2018 at 10:40:29AM -0700, Jonathan Corbet wrote:
> On Sun, 30 Dec 2018 17:49:45 +0100
> Otto Sabart wrote:
>
> > The graphviz looks better. This patch also fixes multiple build warnings:
> > "WARNING: Block quote ends without a blank line; unexpected unindent."
> >
> > Signed-off
Hello, Paolo.
On Sun, Dec 23, 2018 at 12:00:14PM +0100, Paolo Valente wrote:
> 4.21 is coming ... and the legacy proportional share interface will
> be gone with cfq. This will break legacy code using the
> proportional-share interface on top of bfq. This code may just fail
> when trying to use
Hello, Paolo.
On Tue, Dec 18, 2018 at 08:48:10AM +0100, Paolo Valente wrote:
> If Tejun cannot see any solution to his concern, then can we just
> switch to this extension, considering that
> - for non-shared names the interface is *identical* to the current
> one;
> - by using this new interfac
On Fri, Nov 30, 2018 at 03:47:41PM -0800, Roman Gushchin wrote:
> + * nr_descendants and nr_dying_descendants are protected
> + * by cgroup_mutex and css_set_lock.
Can you be a bit more specific - hold both for writes, either for
reads.
Thanks.
--
tejun
Hello, Paolo.
On Fri, Nov 30, 2018 at 07:23:24PM +0100, Paolo Valente wrote:
> > Then we understood that exactly the same happens with throttling, in
> > case the latter is activated on different devices w.r.t. bfq.
> >
> > In addition, the same may happen, in the near future, with the
> > bandwi
Hello, Paolo.
On Mon, Nov 19, 2018 at 11:34:14AM +0100, Paolo Valente wrote:
> - if all entities produce the same output, the this common output is
> shown only once;
> - if the outputs differ, then every per-entity output is shown,
> followed by the name of the entity that produced that output.
Applied to cgroup/for-4.21.
Thanks a lot, Waiman!
--
tejun
Hello,
On Tue, Nov 06, 2018 at 09:06:01AM -0500, Waiman Long wrote:
> On 11/06/2018 06:55 AM, Peter Zijlstra wrote:
> > On Tue, Nov 06, 2018 at 12:53:35PM +0100, Peter Zijlstra wrote:
> >> On Mon, Nov 05, 2018 at 08:36:56AM -0800, Tejun Heo wrote:
> >>> Hello,
>
Hello, again, guys.
On Tue, Nov 06, 2018 at 09:09:07AM -0500, Tejun Heo wrote:
> Hello, Waiman, Peter.
>
> Let's skip this patch for now. I'll think more about the interface and
> adapt your patch later.
Sorry about the last message. I thought I configured web interfac
Hello,
So, this looks good to me. Peter, I'm gonna roll the series into
cgroup/for-4.21-cpuset. Please holler if you have any objections /
comments.
Thanks.
--
tejun
On Fri, Oct 19, 2018 at 02:56:13PM -0400, Waiman Long wrote:
> On 10/17/2018 11:08 AM, Tejun Heo wrote:
> > On Mon, Oct 15, 2018 at 04:29:37PM -0400, Waiman Long wrote:
> >> Currently, cpuset.sched.partition returns the values, 0, 1 or -1 on
> >> read. A person w
er-friendly, it will
> now display the following descriptive text on read:
>
> "normal" - A normal cpuset, not a partition root
> "partition" - A partition root
> "partition invalid" - An invalid partition root
>
> Suggested-by: Tejun Heo
>
Hello, Waiman.
This looks great to me. I have only one small nit in terms of
interface. Currently, cpuset.partition file uses -1, 0, 1; however,
given that this is consistent with how cgroup.type behaves (something
can be set but may be invalid), I wonder whether using a similar
syntax would be
Hello, Waiman.
My apologies for the delay.
On Mon, Aug 27, 2018 at 01:50:18PM -0400, Waiman Long wrote:
> My current code has explicitly assumed the following relationship for
> partition root.
>
> cpus_allowed = effective_cpus + reserved_cpus
>
> Also effective_cpus cannot be empty. Specif
On Wed, Jul 11, 2018 at 05:21:05PM +0200, Sebastian Andrzej Siewior wrote:
> ata_sff_data_xfer_noirq() is invoked via the ->sff_data_xfer hook. The
> latter is invoked by ata_pio_sector(), atapi_send_cdb() and
> __atapi_pio_bytes() which in turn is invoked by ata_sff_hsm_move().
> The latter functi
On Wed, May 09, 2018 at 10:18:45AM -0300, Mauro Carvalho Chehab wrote:
> The cgroup-v2.txt is already in ReST format. So, move it to the
> admin-guide, where it belongs.
>
> Cc: Tejun Heo
> Cc: Li Zefan
> Cc: Johannes Weiner
> Signed-off-by: Mauro Carvalho Chehab
Acked-b
Hello, Sebastian.
On Fri, May 04, 2018 at 05:06:20PM +0200, Sebastian Andrzej Siewior wrote:
> ata_sff_data_xfer_noirq() is invoked via the ->sff_data_xfer hook. The
> latter is invoked by ata_pio_sector(), atapi_send_cdb() and
> __atapi_pio_bytes() which in turn is invoked by ata_sff_hsm_move().
Hello,
On Tue, May 01, 2018 at 04:33:45PM -0400, Waiman Long wrote:
> I think that will work too. We currently don't have a flag to make a
> file visible on first-level children only, but it shouldn't be hard to
> make one.
I think it'd be fine to make the flag file exist on all !root cgroups
but
Hello, Waiman.
Sorry about the delay.
On Thu, Apr 19, 2018 at 09:47:03AM -0400, Waiman Long wrote:
> With the addition of "cpuset.cpus.isolated", it makes sense to add the
> restriction that load balancing can only be turned off if the CPUs in
> the isolated cpuset are subset of "cpuset.cpus.isol
Hello,
On Mon, Mar 26, 2018 at 04:28:49PM -0400, Waiman Long wrote:
> Maybe we can have a different root level flag, say,
> sched_partition_domain that is equivalent to !sched_load_balnace.
> However, I am still not sure if we should enforce that no task should be
> in the root cgroup when the fla
Hello,
On Tue, Mar 20, 2018 at 04:53:37PM -0400, Waiman Long wrote:
> ASAIK for v2, when cpuset.cpus is empty, cpuset.effective_cpus will show
> all the cpus available from the parent. It is a different behavior from
> v1. So do we still need a cpuset.cpus_available?
Heh, you're right. Let's for
Hello, Waiman.
On Tue, Mar 20, 2018 at 04:12:25PM -0400, Waiman Long wrote:
> After some thought, I am planning to impose the following additional
> constraints on how sched_load_balance works in v2.
>
> 1) sched_load_balance will be made hierarchical, the child will inherit
> the flag from its p
Hello, Waiman.
On Tue, Mar 20, 2018 at 09:51:20AM -0400, Waiman Long wrote:
> >> + It lists the onlined CPUs that are actually allowed to be
> >> + used by tasks within the current cgroup. It is a subset of
> >> + "cpuset.cpus". Its value will be affected by CPU hotplug
> >> + events.
> > Can
Hello, Waiman.
This looks great. A couple nitpicks below.
> + 5-3. Cpuset
> + 5.3-1. Cpuset Interface Files
Can we put cpuset below pid? It feels weird to break up cpu, memory
and io as they represent the three major resources and are in a
similar fashion.
> + cpuset.effective_cpus
Hello, Waiman.
On Thu, Mar 15, 2018 at 05:20:42PM -0400, Waiman Long wrote:
> + The currently supported flag is:
> +
> + sched_load_balance
> + When it is not set, there will be no load balancing
> + among CPUs on this cpuset. Tasks will stay in the
> +
Hello, Mike.
On Thu, Mar 15, 2018 at 03:49:01AM +0100, Mike Galbraith wrote:
> Under the hood v2 details are entirely up to you. My input ends at
> please don't leave dynamic partitioning standing at the dock when v2
> sails.
So, this isn't about implementation details but about what the
interfa
Hello,
On Sat, Mar 10, 2018 at 04:47:28AM +0100, Mike Galbraith wrote:
> Some form of cpu_exclusive (preferably exactly that, but something else
> could replace it) is needed to define sets that must not overlap any
> other set at creation time or any time thereafter. A set with property
> 'exclu
On Tue, Jan 30, 2018 at 05:42:13PM +0100, Florian Schmidt wrote:
> There is no entry file_mapped in the memory.stat file. This looks like a
> simple word flip that's gone unnoticed since 2010 (dc10e281f5fc,
> memcg: update documentation).
>
> Signed-off-by: Florian Schmidt
Applied to cgroup/for-
. This might result in an over accounting because of the
> oom_score_adj setting. Document this for now.
>
> Acked-by: Roman Gushchin
> Signed-off-by: Michal Hocko
Acked-by: Tejun Heo
Thanks, Michal.
--
tejun
--
To unsubscribe from this list: send the line "unsubscrib
Hello, Michal.
On Mon, Jan 29, 2018 at 11:46:57AM +0100, Michal Hocko wrote:
> @@ -1292,7 +1292,11 @@ the memory controller considers only cgroups belonging
> to the sub-tree
> of the OOM'ing cgroup.
>
> The root cgroup is treated as a leaf memory cgroup, so it's compared
> -with other leaf m
Hello, Andrew.
On Wed, Jan 24, 2018 at 02:08:05PM -0800, Andrew Morton wrote:
> Can we please try to narrow the scope of this issue by concentrating on
> the userspace interfaces? David believes that the mount option and
> memory.oom_group will disappear again in the near future, others
> disagre
Hello, David.
On Fri, Jan 19, 2018 at 12:53:41PM -0800, David Rientjes wrote:
> Hearing no response, I'll implement this as a separate tunable in a v2
> series assuming there are no better ideas proposed before next week. One
> of the nice things about a separate tunable is that an admin can co
Hello, David.
On Tue, Jan 16, 2018 at 06:15:08PM -0800, David Rientjes wrote:
> The behavior of killing an entire indivisible memory consumer, enabled
> by memory.oom_group, is an oom policy itself. It specifies that all
I thought we discussed this before but maybe I'm misremembering.
There are
On Wed, Jan 10, 2018 at 11:33:19PM +0100, Maciej S. Szmigiero wrote:
> Currently, cgroups v2 documentation contains only a generic remark that
> "How resource consumption in the root cgroup is governed is up to each
> controller", which isn't really telling users much, who need to dig in the
> code
Hello,
On Thu, Jan 04, 2018 at 10:57:00PM +0100, Maciej S. Szmigiero wrote:
> Currently, cgroups v2 documentation contains only a generic remark that
> "How resource consumption in the root cgroup is governed is up to each
> controller", which isn't really telling users much, who need to dig in th
On Tue, Jan 02, 2018 at 05:27:41PM +0100, Vladimir Rutsky wrote:
> Signed-off-by: Vladimir Rutsky
Applied to cgroup/for-4.16.
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at h
point the user to the v1 docs.
>
> Cc: Tejun Heo
> Cc: linux-doc@vger.kernel.org
> Signed-off-by: Matt Roper
Applied 1-2 to cgroup/for-4.16.
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...
Hello, Shakeel.
On Thu, Dec 21, 2017 at 07:22:20AM -0800, Shakeel Butt wrote:
> I am claiming memory allocations under global pressure will be
> affected by the performance of the underlying swap device. However
> memory allocations under memcg memory pressure, with memsw, will not
> be affected b
Hello, Shakeel.
On Wed, Dec 20, 2017 at 05:15:41PM -0800, Shakeel Butt wrote:
> Let's say we have a job that allocates 100 MiB memory and suppose 80
> MiB is anon and 20 MiB is non-anon (file & kmem).
>
> [With memsw] Scheduler sets the memsw limit of the job to 100 MiB and
> memory to max. Now s
Hello, Shakeel.
On Wed, Dec 20, 2017 at 12:15:46PM -0800, Shakeel Butt wrote:
> > I don't understand how this invariant is useful across different
> > backing swap devices and availability. e.g. Our OOM decisions are
> > currently not great in that the kernel can easily thrash for a very
> > long
Hello, Shakeel.
On Tue, Dec 19, 2017 at 02:39:19PM -0800, Shakeel Butt wrote:
> Suppose a user wants to run multiple instances of a specific job on
> different datacenters and s/he has budget of 100MiB for each instance.
> The instances are schduled on the requested datacenters and the
> scheduler
Hello,
On Tue, Dec 19, 2017 at 10:25:12AM -0800, Shakeel Butt wrote:
> Making the runtime environment, an invariant is very critical to make
> the management of a job easier whose instances run on different
> clusters across the world. Some clusters might have different type of
> swaps installed w
Hello,
On Tue, Dec 19, 2017 at 09:23:29AM -0800, Shakeel Butt wrote:
> To provide consistent memory usage history using the current
> cgroup-v2's 'swap' interface, an additional metric expressing the
> intersection of memory and swap has to be exposed. Basically memsw is
> the union of memory and
Hello,
On Tue, Dec 19, 2017 at 07:12:19AM -0800, Shakeel Butt wrote:
> Yes, there are pros & cons, therefore we should give users the option
> to select the API that is better suited for their use-cases and
Heh, that's not how API decisions should be made. The long term
outcome would be really r
On Wed, Dec 13, 2017 at 07:49:03PM +, Roman Gushchin wrote:
> Add the corresponding section in cgroup v2 documentation.
>
> Signed-off-by: Roman Gushchin
> Cc: Tejun Heo
> Cc: Alexei Starovoitov
> Cc: kernel-t...@fb.com
> Cc: cgro...@vger.kernel.org
> Cc: linux-
Hello, Waiman.
On Mon, Nov 27, 2017 at 04:19:57PM -0500, Waiman Long wrote:
> > Let's start just with [e]cpus and [e]mems. The flags interface looks
> > fine but the implementations of these features are really bad and
> > cgroup2 doesn't migrate resources for other controllers either anyway.
>
Hello, Waiman.
Sorry about the long delay.
On Fri, Oct 06, 2017 at 05:10:30PM -0400, Waiman Long wrote:
> +Cpuset Interface Files
> +~~
> +
> + cpuset.cpus
> + A read-write multiple values file which exists on non-root
> + cgroups.
> +
> + It lists the CPUs allowe
On Sun, Oct 29, 2017 at 05:36:53PM +0100, Maciej S. Szmigiero wrote:
> CFQ scheduler has a property that processes (or tasks in cgroups v1) that
> aren't assigned to any particular cgroup - that is, which stay in the root
> cgroup - effectively form an implicit leaf child node attached to the root
Hello, Waiman.
On Wed, Oct 25, 2017 at 11:50:34AM -0400, Waiman Long wrote:
> Ping! Any comment on this patch?
Sorry about the lack of response. Here are my two thoughts.
1. I'm not really sure about the memory part. Mostly because of the
way it's configured and enforced is completely out o
Hello, Michal.
On Thu, Oct 05, 2017 at 03:14:19PM +0200, Michal Hocko wrote:
> Yes and that is why I think a boot time knob would be the most simple
> way. It will also open doors for more oom policies in future which I
> believe come sooner or later.
While boot params are fine for development an
Hello, Michal.
On Tue, Oct 03, 2017 at 04:22:46PM +0200, Michal Hocko wrote:
> On Tue 03-10-17 15:08:41, Roman Gushchin wrote:
> > On Tue, Oct 03, 2017 at 03:36:23PM +0200, Michal Hocko wrote:
> [...]
> > > I guess we want to inherit the value on the memcg creation but I agree
> > > that enforcing
Hello,
On Fri, Sep 22, 2017 at 01:39:55PM -0700, David Rientjes wrote:
> Current heuristic based on processes is coupled with per-process
> /proc/pid/oom_score_adj. The proposed
> heuristic has no ability to be influenced by userspace, and it needs one.
> The proposed heuristic based on memory
Hello, David.
On Thu, Sep 21, 2017 at 02:17:25PM -0700, David Rientjes wrote:
> It doesn't have anything to do with my particular usecase, but rather the
> ability of userspace to influence the decisions of the kernel. Previous
> to this patchset, when selection is done based on process size, u
- quote one function name
>
> Signed-off-by: Randy Dunlap
> Cc: Tejun Heo
> Cc: Florian Mickler
Applied to wq/for-4.14-fixes.
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello,
On Wed, Aug 16, 2017 at 10:34:05AM -0400, Waiman Long wrote:
> > It feels weird to make this a kernel boot param when all other options
> > are specified on mount time. Is there a reason why this can't be a
> > mount option too?
> >
> Yes, we can certainly make this a mount option instead
Hello, Waiman.
On Tue, Aug 15, 2017 at 01:27:20PM -0400, Waiman Long wrote:
> + cpuset_v2_mode= [KNL] Enable cpuset v2 behavior in cpuset v1 cgroups.
> + In v2 mode, the cpus and mems can be restored to
> + their original values after a removal-addition
Hello, Roman.
Generally looks good to me. One minor nit.
On Wed, Aug 02, 2017 at 05:55:30PM +0100, Roman Gushchin wrote:
> +static ssize_t cgroup_max_descendants_write(struct kernfs_open_file *of,
> +char *buf, size_t nbytes, loff_t off)
> +{
> + struc
Hello,
On Fri, Jul 28, 2017 at 02:01:55PM +0100, Roman Gushchin wrote:
> > > + nr_dying_descendants
> > > + Total number of dying descendant cgroups.
> >
> > Can you please go into more detail on what's going on with dying
> > descendants here?
>
> Sure.
> Don't we plan do describe cgro
Hello,
On Thu, Jul 27, 2017 at 05:14:20PM +0100, Roman Gushchin wrote:
> Add a cgroup.stat interface to the base cgroup control files
> with the following metrics:
>
> nr_descendantstotal number of descendant cgroups
> nr_dying_descendants total number of dying descendant cgroups
Hello, Andrew.
Can you please apply Mauro's doc format update patch for
cgroup-v2.txt? The mm part causes conflicts, so I think it'd be
easier to route it through -mm.
The patch to apply is in the following message.
https://marc.info/?l=linux-cgroups&m=149771274105674&q=raw
Thanks.
--
tejun
Hello,
On Fri, Jun 02, 2017 at 04:36:22PM -0400, Waiman Long wrote:
> I wouldn't argue further on that if you insist. However, I still want to
Oh, please don't get me wrong. I'm not trying to shut down the
discussion or anything. It's just that whole-scope discussions can
get very meandering an
Hello,
On Thu, Jun 01, 2017 at 05:12:42PM -0400, Waiman Long wrote:
> Are you referring to keeping the no internal process restriction and
> document how to work around that instead? I would like to hear what
> workarounds are currently being used.
What we've been talking about all along - just c
Hello,
On Thu, Jun 01, 2017 at 04:48:48PM -0400, Waiman Long wrote:
> I think we are on agreement here. I should we should just document how
> userland can work around the internal process competition issue by
> setting up the cgroup hierarchy properly. Then we can remove the no
> internal process
Hello,
On Thu, Jun 01, 2017 at 03:27:35PM -0400, Waiman Long wrote:
> As said in an earlier email, I agreed that masking it on the kernel side
> may not be the best solution. I offer 2 other alternatives:
> 1) Document on how to work around the resource domains issue by proper
> setup of the cgrou
Hello, Waiman.
On Thu, Jun 01, 2017 at 02:44:48PM -0400, Waiman Long wrote:
> > And cgroup-v2 has this 'exception' (aka wart) for the root group which
> > needs to be replicated for each namespace.
>
> One of the changes that I proposed in my patches was to get rid of the
> no internal process co
Hello, Peter.
On Thu, Jun 01, 2017 at 05:10:45PM +0200, Peter Zijlstra wrote:
> I've not had time to look at any of this. But the question I'm most
> curious about is how cgroup-v2 preserves the container invariant.
>
> That is, each container (namespace) should look like a 'real' machine.
> So j
Hello, Waiman.
A short update. I tried making root special while keeping the
existing threaded semantics but I didn't really like it because we
have to couple controller enables/disables with threaded
enables/disables. I'm now trying a simpler, albeit a bit more
tedious, approach which should le
Hello,
On Wed, May 24, 2017 at 05:17:13PM -0400, Waiman Long wrote:
> An alternative is to have separate enabling for thread root. For example,
>
> # echo root > cgroup.threads
> # echo enable > child/cgroup.threads
>
> The first statement make the current cgroup the thread root. However,
> sett
Hello, Waiman.
On Mon, May 22, 2017 at 01:13:16PM -0400, Waiman Long wrote:
> > Maybe I'm misunderstanding the design, but this seems to push the
> > processes which belong to the threaded subtree to the parent which is
> > part of the usual resource domain hierarchy thus breaking the no
> > inter
Hello,
On Wed, May 24, 2017 at 01:49:46PM -0400, Waiman Long wrote:
> What I am saying is as follows:
> / A
> P - B
>\ C
>
> # echo +memory > P/cgroups.subtree_control
> # echo -memory > P/A/cgroup.controllers
> # echo "#memory" > P/B/cgroup.controllers
>
> The parent grants the memory c
Hello, Waiman.
On Fri, May 19, 2017 at 05:20:01PM -0400, Waiman Long wrote:
> > This breaks the invariant that in a cgroup its resource control knobs
> > control distribution of resources from its parent. IOW, the resource
> > control knobs of a cgroup always belong to the parent. This is also
>
Hello, Mike.
On Sat, May 20, 2017 at 04:10:07AM +0200, Mike Galbraith wrote:
> On Fri, 2017-05-19 at 16:38 -0400, Tejun Heo wrote:
> > Hello, Waiman.
> >
> > On Mon, May 15, 2017 at 09:34:11AM -0400, Waiman Long wrote:
> > > The rationale behind the cgroup v2 no
Hello,
On Mon, May 22, 2017 at 12:56:08PM -0400, Waiman Long wrote:
> All controllers can use the special sub-directory if userland chooses to
> do so. The problem that I am trying to address in this patch is to allow
> more natural hierarchy that reflect a certain purpose, like the task
> classif
Hello,
On Fri, May 19, 2017 at 04:26:24PM -0400, Tejun Heo wrote:
> (exactly in the way necessary), I wonder whether it'd be better to
> simply allow root to be both domain and thread root.
I'll give this approach a shot early next week.
Thanks.
--
tejun
--
To unsubscribe from
Hello, Waiman.
On Mon, May 15, 2017 at 09:34:12AM -0400, Waiman Long wrote:
> For cgroup v1, different controllers can be binded to different cgroup
> hierarchies optimized for their own use cases. That is not currently
> the case for cgroup v2 where combining all these controllers into
> the same
Hello, Waiman.
On Mon, May 15, 2017 at 09:34:11AM -0400, Waiman Long wrote:
> The rationale behind the cgroup v2 no internal process constraint is
> to avoid resouorce competition between internal processes and child
> cgroups. However, not all controllers have problem with internal
> process comp
Hello,
On Fri, May 19, 2017 at 03:33:14PM -0400, Waiman Long wrote:
> On 05/19/2017 03:21 PM, Tejun Heo wrote:
> > Yeah but it also shows up as an integral part of stable interface
> > rather than e.g. /sys/kernel/debug. This isn't of any interest to
> > people who are
Hello, Waiman.
On Mon, May 15, 2017 at 09:34:10AM -0400, Waiman Long wrote:
> Now we could have something like
>
> R -- A -- B
>\
> T1 -- T2
>
> where R is the thread root, A and B are non-threaded cgroups, T1 and
> T2 are threaded cgroups. The cgroups R, T1, T2 form a thre
Hello, Waiman.
On Thu, May 18, 2017 at 11:52:18AM -0400, Waiman Long wrote:
> The controller name is "debug" and so it is obvious what this controller
> is for. However, the config prompt "Example controller" is indeed vague
Yeah but it also shows up as an integral part of stable interface
rather
Hello, Mauro.
On Thu, May 18, 2017 at 10:22:11PM -0300, Mauro Carvalho Chehab wrote:
> Each text file under Documentation follows a different
> format. Some doesn't even have titles!
>
> Change its representation to follow the adopted standard,
> using ReST markups for it to be parseable by Sphin
Hello, Waiman.
On Mon, May 15, 2017 at 09:34:10AM -0400, Waiman Long wrote:
> The current thread mode semantics aren't sufficient to fully support
> threaded controllers like cpu. The main problem is that when thread
> mode is enabled at root (mainly for performance reason), all the
> non-threaded
Hello,
On Mon, May 15, 2017 at 09:34:09AM -0400, Waiman Long wrote:
> Besides supporting cgroup v2 and thread mode, the following changes
> are also made:
> 1) current_* cgroup files now resides only at the root as we don't
> need duplicated files of the same function all over the cgroup
>
Hello,
On Mon, May 15, 2017 at 09:34:08AM -0400, Waiman Long wrote:
> The reference count in the css_set data structure was used as a
> proxy of the number of tasks attached to that css_set. However, that
> count is actually not an accurate measure especially with thread mode
> support. So a new v
On Wed, May 17, 2017 at 04:24:32PM -0400, Waiman Long wrote:
> On 05/17/2017 03:23 PM, Tejun Heo wrote:
> > Hello,
> >
> > On Mon, May 15, 2017 at 09:34:06AM -0400, Waiman Long wrote:
> >> The kill_css() function may be called more than once under the condition
> &
Hello, Waiman.
On Mon, May 15, 2017 at 09:34:07AM -0400, Waiman Long wrote:
> The debug cgroup currently resides within cgroup-v1.c and is enabled
> only for v1 cgroup. To enable the debug cgroup also for v2, it
> makes sense to put the code into its own file as it will no longer
> be v1 specific.
Hello,
On Mon, May 15, 2017 at 09:34:06AM -0400, Waiman Long wrote:
> The kill_css() function may be called more than once under the condition
> that the css was killed but not physically removed yet followed by the
> removal of the cgroup that is hosting the css. This patch prevents any
> harmm f
to match the get_task_struct() in cgroup_procs_write_start() to fix
> this reference counting error.
>
> Signed-off-by: Waiman Long
Acked-by: Tejun Heo
Thanks!
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...
Hello, Waiman.
On Wed, Apr 26, 2017 at 12:05:27PM -0400, Waiman Long wrote:
> Does anyone has time to take a look at these patches?
>
> As the merge window is going to open up next week, I am not going to
> bother you guys when the merge window opens.
Will get to it next week. Sorry about the d
On Tue, Jan 10, 2017 at 12:02:12AM +, Parav Pandit wrote:
> Patchset is compiled and tested against below Tejun's cgroup tree
> using cgroup v1 and v2 mode.
> URL: git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup.git
> Branch: for-4.11
Applied 1-3 to cgroup/for-4.11-rdmacg.
Thanks.
--
On Mon, Jan 09, 2017 at 02:01:26PM -0600, Parav Pandit wrote:
> I will generate new patch in sometime this week with for-4.11 to
> address comments and rebase.
> I will be renaming cgroup_rdma.c to kernel/cgroup/rdma.c (similar to pids.c)
>
> I will keep the header file name include/linux/cgroup_r
On Fri, Dec 02, 2016 at 07:07:14PM +, Parav Pandit wrote:
> Patch is generated and tested against below Doug's linux-rdma
> git tree.
> URL: git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma.git
> Branch: master
>
> Patchset is also compiled and tested against below Tejun's cgroup tr
On Fri, Dec 02, 2016 at 07:07:16PM +, Parav Pandit wrote:
> Added support APIs for IB core to register/unregister every IB/RDMA
> device with rdma cgroup for tracking rdma resources.
> IB core registers with rdma cgroup controller.
> Added support APIs for uverbs layer to make use of rdma contr
Hello, Parav.
Looks good to me. Just one minor nit below.
> +static void rdmacg_uncharge_hirerchy(struct rdma_cgroup *cg,
hierarchy
Other than that, looks good to me.
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord
1 - 100 of 151 matches
Mail list logo
