linux-next.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* linux-next: manual merge of the cgroup tree with Linus' tree
@ 2015-12-07  6:36 Stephen Rothwell
  2015-12-07 15:20 ` Tejun Heo
  0 siblings, 1 reply; 7+ messages in thread
From: Stephen Rothwell @ 2015-12-07  6:36 UTC (permalink / raw)
  To: Tejun Heo; +Cc: linux-next, linux-kernel, Nina Schiff, David S. Miller

Hi Tejun,

Today's linux-next merge of the cgroup tree got a conflict in:

  net/core/netclassid_cgroup.c

between commit:

  3b13758f51de ("cgroups: Allow dynamically changing net_classid")

from Linus' tree and commit:

  1f7dd3e5a6e4 ("cgroup: fix handling of multi-destination migration from subtree_control enabling")

from the cgroup tree.

I couldn't figure out how to fix this up, so I have just dropped the
cgroup tree for today.

Tejun, maybe you could merge Linus' tree (probably -rc4?) and fix this
up yourself?

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: linux-next: manual merge of the cgroup tree with Linus' tree
  2015-12-07  6:36 linux-next: manual merge of the cgroup tree with Linus' tree Stephen Rothwell
@ 2015-12-07 15:20 ` Tejun Heo
  2015-12-07 20:19   ` Stephen Rothwell
  0 siblings, 1 reply; 7+ messages in thread
From: Tejun Heo @ 2015-12-07 15:20 UTC (permalink / raw)
  To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Nina Schiff, David S. Miller

Hello,

Resolved from cgroup/for-4.4-fixes side.

Thanks.

------ 8< ------
commit 0b98f0c04245877ae0b625a7f0aa55b8ff98e0c4
Merge: 67cde9c 527e931
Author: Tejun Heo <tj@kernel.org>
Date:   Mon Dec 7 10:09:03 2015 -0500

    Merge branch 'master' into for-4.4-fixes
    
    The following commit which went into mainline through networking tree
    
      3b13758f51de ("cgroups: Allow dynamically changing net_classid")
    
    conflicts in net/core/netclassid_cgroup.c with the following pending
    fix in cgroup/for-4.4-fixes.
    
      1f7dd3e5a6e4 ("cgroup: fix handling of multi-destination migration from subtree_control enabling")
    
    The former separates out update_classid() from cgrp_attach() and
    updates it to walk all fds of all tasks in the target css so that it
    can be used from both migration and config change paths.  The latter
    drops @css from cgrp_attach().
    
    Resolve the conflict by making cgrp_attach() call update_classid()
    with the css from the first task.  We can revive @tset walking in
    cgrp_attach() but given that net_cls is v1 only where there always is
    only one target css during migration, this is fine.
    
    Signed-off-by: Tejun Heo <tj@kernel.org>
    Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
    Cc: Nina Schiff <ninasc@fb.com>

diff --cc net/core/netclassid_cgroup.c
index 81cb3c7,2e4df84..d9ee8d0
--- a/net/core/netclassid_cgroup.c
+++ b/net/core/netclassid_cgroup.c
@@@ -67,19 -67,25 +67,27 @@@ static int update_classid_sock(const vo
  	return 0;
  }
  
- static void cgrp_attach(struct cgroup_taskset *tset)
+ static void update_classid(struct cgroup_subsys_state *css, void *v)
  {
+ 	struct css_task_iter it;
  	struct task_struct *p;
- 	struct cgroup_subsys_state *css;
- 
- 	cgroup_taskset_for_each(p, css, tset) {
- 		struct cgroup_cls_state *cs = css_cls_state(css);
- 		void *v = (void *)(unsigned long)cs->classid;
  
+ 	css_task_iter_start(css, &it);
+ 	while ((p = css_task_iter_next(&it))) {
  		task_lock(p);
- 		iterate_fd(p->files, 0, update_classid, v);
+ 		iterate_fd(p->files, 0, update_classid_sock, v);
  		task_unlock(p);
  	}
+ 	css_task_iter_end(&it);
+ }
+ 
 -static void cgrp_attach(struct cgroup_subsys_state *css,
 -			struct cgroup_taskset *tset)
++static void cgrp_attach(struct cgroup_taskset *tset)
+ {
++	struct cgroup_subsys_state *css;
++
++	cgroup_taskset_first(tset, &css);
+ 	update_classid(css,
+ 		       (void *)(unsigned long)css_cls_state(css)->classid);
  }
  
  static u64 read_classid(struct cgroup_subsys_state *css, struct cftype *cft)

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: linux-next: manual merge of the cgroup tree with Linus' tree
  2015-12-07 15:20 ` Tejun Heo
@ 2015-12-07 20:19   ` Stephen Rothwell
  0 siblings, 0 replies; 7+ messages in thread
From: Stephen Rothwell @ 2015-12-07 20:19 UTC (permalink / raw)
  To: Tejun Heo; +Cc: linux-next, linux-kernel, Nina Schiff, David S. Miller

Hi Tejun,

On Mon, 7 Dec 2015 10:20:32 -0500 Tejun Heo <tj@kernel.org> wrote:
>
> Resolved from cgroup/for-4.4-fixes side.

Excellent, thanks!

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

^ permalink raw reply	[flat|nested] 7+ messages in thread

* Re: linux-next: manual merge of the cgroup tree with Linus' tree
  2019-06-17  6:06 Stephen Rothwell
@ 2019-07-08 23:25 ` Stephen Rothwell
  0 siblings, 0 replies; 7+ messages in thread
From: Stephen Rothwell @ 2019-07-08 23:25 UTC (permalink / raw)
  To: Tejun Heo
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Andreas Herrmann, Jens Axboe, Mauro Carvalho Chehab

[-- Attachment #1: Type: text/plain, Size: 3931 bytes --]

Hi all,

On Mon, 17 Jun 2019 16:06:35 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the cgroup tree got a conflict in:
> 
>   Documentation/cgroup-v1/blkio-controller.rst
> 
> between commit:
> 
>   fb5772cbfe48 ("blkio-controller.txt: Remove references to CFQ")
> 
> from Linus' tree and commit:
> 
>   99c8b231ae6c ("docs: cgroup-v1: convert docs to ReST and rename to *.rst")
> 
> from the cgroup tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc Documentation/cgroup-v1/blkio-controller.rst
> index d1a1b7bdd03a,2c1b907afc14..000000000000
> --- a/Documentation/cgroup-v1/blkio-controller.rst
> +++ b/Documentation/cgroup-v1/blkio-controller.rst
> @@@ -15,15 -19,71 +17,18 @@@ level logical devices like device mappe
>   
>   HOWTO
>   =====
>  -Proportional Weight division of bandwidth
>  ------------------------------------------
>  -You can do a very simple testing of running two dd threads in two different
>  -cgroups. Here is what you can do.
>  -
>  -- Enable Block IO controller::
>  -
>  -	CONFIG_BLK_CGROUP=y
>  -
>  -- Enable group scheduling in CFQ:
>  -
>  -
>  -	CONFIG_CFQ_GROUP_IOSCHED=y
>  -
>  -- Compile and boot into kernel and mount IO controller (blkio); see
>  -  cgroups.txt, Why are cgroups needed?.
>  -
>  -  ::
>  -
>  -	mount -t tmpfs cgroup_root /sys/fs/cgroup
>  -	mkdir /sys/fs/cgroup/blkio
>  -	mount -t cgroup -o blkio none /sys/fs/cgroup/blkio
>  -
>  -- Create two cgroups::
>  -
>  -	mkdir -p /sys/fs/cgroup/blkio/test1/ /sys/fs/cgroup/blkio/test2
>  -
>  -- Set weights of group test1 and test2::
>  -
>  -	echo 1000 > /sys/fs/cgroup/blkio/test1/blkio.weight
>  -	echo 500 > /sys/fs/cgroup/blkio/test2/blkio.weight
>  -
>  -- Create two same size files (say 512MB each) on same disk (file1, file2) and
>  -  launch two dd threads in different cgroup to read those files::
>  -
>  -	sync
>  -	echo 3 > /proc/sys/vm/drop_caches
>  -
>  -	dd if=/mnt/sdb/zerofile1 of=/dev/null &
>  -	echo $! > /sys/fs/cgroup/blkio/test1/tasks
>  -	cat /sys/fs/cgroup/blkio/test1/tasks
>  -
>  -	dd if=/mnt/sdb/zerofile2 of=/dev/null &
>  -	echo $! > /sys/fs/cgroup/blkio/test2/tasks
>  -	cat /sys/fs/cgroup/blkio/test2/tasks
>  -
>  -- At macro level, first dd should finish first. To get more precise data, keep
>  -  on looking at (with the help of script), at blkio.disk_time and
>  -  blkio.disk_sectors files of both test1 and test2 groups. This will tell how
>  -  much disk time (in milliseconds), each group got and how many sectors each
>  -  group dispatched to the disk. We provide fairness in terms of disk time, so
>  -  ideally io.disk_time of cgroups should be in proportion to the weight.
>  -
>   Throttling/Upper Limit policy
>   -----------------------------
> - - Enable Block IO controller
> + - Enable Block IO controller::
> + 
>   	CONFIG_BLK_CGROUP=y
>   
> - - Enable throttling in block layer
> + - Enable throttling in block layer::
> + 
>   	CONFIG_BLK_DEV_THROTTLING=y
>   
> - - Mount blkio controller (see cgroups.txt, Why are cgroups needed?)
> + - Mount blkio controller (see cgroups.txt, Why are cgroups needed?)::
> + 
>           mount -t cgroup -o blkio none /sys/fs/cgroup/blkio
>   
>   - Specify a bandwidth rate on particular device for root group. The format

I am still getting this conflict (the commit ids may have changed).
Just a reminder in case you think Linus may need to know.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

* linux-next: manual merge of the cgroup tree with Linus' tree
@ 2019-06-17  6:06 Stephen Rothwell
  2019-07-08 23:25 ` Stephen Rothwell
  0 siblings, 1 reply; 7+ messages in thread
From: Stephen Rothwell @ 2019-06-17  6:06 UTC (permalink / raw)
  To: Tejun Heo
  Cc: Linux Next Mailing List, Linux Kernel Mailing List,
	Andreas Herrmann, Jens Axboe, Mauro Carvalho Chehab

[-- Attachment #1: Type: text/plain, Size: 3473 bytes --]

Hi all,

Today's linux-next merge of the cgroup tree got a conflict in:

  Documentation/cgroup-v1/blkio-controller.rst

between commit:

  fb5772cbfe48 ("blkio-controller.txt: Remove references to CFQ")

from Linus' tree and commit:

  99c8b231ae6c ("docs: cgroup-v1: convert docs to ReST and rename to *.rst")

from the cgroup tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc Documentation/cgroup-v1/blkio-controller.rst
index d1a1b7bdd03a,2c1b907afc14..000000000000
--- a/Documentation/cgroup-v1/blkio-controller.rst
+++ b/Documentation/cgroup-v1/blkio-controller.rst
@@@ -15,15 -19,71 +17,18 @@@ level logical devices like device mappe
  
  HOWTO
  =====
 -Proportional Weight division of bandwidth
 ------------------------------------------
 -You can do a very simple testing of running two dd threads in two different
 -cgroups. Here is what you can do.
 -
 -- Enable Block IO controller::
 -
 -	CONFIG_BLK_CGROUP=y
 -
 -- Enable group scheduling in CFQ:
 -
 -
 -	CONFIG_CFQ_GROUP_IOSCHED=y
 -
 -- Compile and boot into kernel and mount IO controller (blkio); see
 -  cgroups.txt, Why are cgroups needed?.
 -
 -  ::
 -
 -	mount -t tmpfs cgroup_root /sys/fs/cgroup
 -	mkdir /sys/fs/cgroup/blkio
 -	mount -t cgroup -o blkio none /sys/fs/cgroup/blkio
 -
 -- Create two cgroups::
 -
 -	mkdir -p /sys/fs/cgroup/blkio/test1/ /sys/fs/cgroup/blkio/test2
 -
 -- Set weights of group test1 and test2::
 -
 -	echo 1000 > /sys/fs/cgroup/blkio/test1/blkio.weight
 -	echo 500 > /sys/fs/cgroup/blkio/test2/blkio.weight
 -
 -- Create two same size files (say 512MB each) on same disk (file1, file2) and
 -  launch two dd threads in different cgroup to read those files::
 -
 -	sync
 -	echo 3 > /proc/sys/vm/drop_caches
 -
 -	dd if=/mnt/sdb/zerofile1 of=/dev/null &
 -	echo $! > /sys/fs/cgroup/blkio/test1/tasks
 -	cat /sys/fs/cgroup/blkio/test1/tasks
 -
 -	dd if=/mnt/sdb/zerofile2 of=/dev/null &
 -	echo $! > /sys/fs/cgroup/blkio/test2/tasks
 -	cat /sys/fs/cgroup/blkio/test2/tasks
 -
 -- At macro level, first dd should finish first. To get more precise data, keep
 -  on looking at (with the help of script), at blkio.disk_time and
 -  blkio.disk_sectors files of both test1 and test2 groups. This will tell how
 -  much disk time (in milliseconds), each group got and how many sectors each
 -  group dispatched to the disk. We provide fairness in terms of disk time, so
 -  ideally io.disk_time of cgroups should be in proportion to the weight.
 -
  Throttling/Upper Limit policy
  -----------------------------
- - Enable Block IO controller
+ - Enable Block IO controller::
+ 
  	CONFIG_BLK_CGROUP=y
  
- - Enable throttling in block layer
+ - Enable throttling in block layer::
+ 
  	CONFIG_BLK_DEV_THROTTLING=y
  
- - Mount blkio controller (see cgroups.txt, Why are cgroups needed?)
+ - Mount blkio controller (see cgroups.txt, Why are cgroups needed?)::
+ 
          mount -t cgroup -o blkio none /sys/fs/cgroup/blkio
  
  - Specify a bandwidth rate on particular device for root group. The format

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

* linux-next: manual merge of the cgroup tree with Linus' tree
@ 2014-05-26  7:45 Stephen Rothwell
  0 siblings, 0 replies; 7+ messages in thread
From: Stephen Rothwell @ 2014-05-26  7:45 UTC (permalink / raw)
  To: Tejun Heo; +Cc: linux-next, linux-kernel, Michal Hocko

[-- Attachment #1: Type: text/plain, Size: 1289 bytes --]

Hi Tejun,

Today's linux-next merge of the cgroup tree got a conflict in
mm/memcontrol.c between commit 6f6acb00514c ("memcg: fix swapcache
charge from kernel thread context") from Linus' tree and commit
ec903c0c858e ("cgroup: rename css_tryget*() to css_tryget_online*()")
from the cgroup tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc mm/memcontrol.c
index 5177c6d4a2dd,b6f91d61b3af..000000000000
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@@ -1077,19 -1074,10 +1074,19 @@@ static struct mem_cgroup *get_mem_cgrou
  
  	rcu_read_lock();
  	do {
 -		memcg = mem_cgroup_from_task(rcu_dereference(mm->owner));
 -		if (unlikely(!memcg))
 +		/*
 +		 * Page cache insertions can happen withou an
 +		 * actual mm context, e.g. during disk probing
 +		 * on boot, loopback IO, acct() writes etc.
 +		 */
 +		if (unlikely(!mm))
  			memcg = root_mem_cgroup;
 +		else {
 +			memcg = mem_cgroup_from_task(rcu_dereference(mm->owner));
 +			if (unlikely(!memcg))
 +				memcg = root_mem_cgroup;
 +		}
- 	} while (!css_tryget(&memcg->css));
+ 	} while (!css_tryget_online(&memcg->css));
  	rcu_read_unlock();
  	return memcg;
  }

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

* linux-next: manual merge of the cgroup tree with Linus' tree
@ 2013-03-14  2:31 Stephen Rothwell
  0 siblings, 0 replies; 7+ messages in thread
From: Stephen Rothwell @ 2013-03-14  2:31 UTC (permalink / raw)
  To: Tejun Heo; +Cc: linux-next, linux-kernel, Andrew Morton, Li Zefan

[-- Attachment #1: Type: text/plain, Size: 856 bytes --]

Hi Tejun,

Today's linux-next merge of the cgroup tree got a conflict in
include/linux/res_counter.h between commit ebf47beb660e
("include/linux/res_counter.h needs errno.h") from Linus' tree and commit
9259826ccb81 ("res_counter: remove include of cgroup.h from
res_counter.h") from the cgroup tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc include/linux/res_counter.h
index c230994,a83a849..0000000
--- a/include/linux/res_counter.h
+++ b/include/linux/res_counter.h
@@@ -13,8 -13,7 +13,8 @@@
   * info about what this counter is.
   */
  
- #include <linux/cgroup.h>
 +#include <linux/errno.h>
+ #include <linux/spinlock.h>
  
  /*
   * The core object. the cgroup that wishes to account for some

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 7+ messages in thread

end of thread, other threads:[~2019-07-08 23:25 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-12-07  6:36 linux-next: manual merge of the cgroup tree with Linus' tree Stephen Rothwell
2015-12-07 15:20 ` Tejun Heo
2015-12-07 20:19   ` Stephen Rothwell
  -- strict thread matches above, loose matches on Subject: below --
2019-06-17  6:06 Stephen Rothwell
2019-07-08 23:25 ` Stephen Rothwell
2014-05-26  7:45 Stephen Rothwell
2013-03-14  2:31 Stephen Rothwell

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).