From mboxrd@z Thu Jan  1 00:00:00 1970
From: rahulimpdocs@gmail.com (Rahul Bhattacharya)
Date: Tue, 20 Sep 2016 14:39:10 +0200
Subject: Changing RT task to a different cgroup
In-Reply-To: <CA+f8H1DbdTGtwgv1e5dzDXAV32HfYEq=SPEfemBbeB4mpGoS1Q@mail.gmail.com>
References: <CA+f8H1DbdTGtwgv1e5dzDXAV32HfYEq=SPEfemBbeB4mpGoS1Q@mail.gmail.com>
Message-ID: <CA+f8H1D8iL8EmEaYpBHM9xK94623T0kjuuNrJR4C9jd3CPRD+A@mail.gmail.com>
To: kernelnewbies@lists.kernelnewbies.org
List-Id: kernelnewbies.lists.kernelnewbies.org

Any idea or feedback for the person to contact?
Thanks

br
rb

On Wed, Sep 14, 2016 at 5:21 PM, Rahul Bhattacharya <rahulimpdocs@gmail.com>
wrote:

> When I try to move a RT task to a different cgroup(shown below) I get a EINVAL error.
>
> However I can change the cgroup first and then change the sched policy.
>
> After looking into kernel source code(*I dont use CONFIG_RT_GROUP_SCHED config*) I was able to extract this piece of logic
>
>
>
> *chrt -p 777*
> pid 777's current scheduling policy: SCHED_OTHER
> pid 777's current scheduling priority: 0
> *cat /proc/777/cgroup*
> 2:cpu,cpuacct:/system.slice
> 1:name=systemd:/system.slice/d.service
> *chrt -f -p 50 777*
>
> root at mgu-high:~# chrt -p 777
> pid 777's current scheduling policy: SCHED_FIFO
> pid 777's current scheduling priority: 50
> */bin/echo 777>/sys/fs/cgroup/cpu,cpuacct/interaction.slice/tasks**echo: write error: Invalid argument*
>
>
> After browsing kernel sources I was able to find out the reason of failure.
>
>
> static int cpu_cgroup_can_attach(struct cgroup_subsys_state *css,
> 				 struct cgroup_taskset *tset)
> {
> 	struct task_struct *task;
>
> 		
> 	cgroup_taskset_for_each(task, tset) {
> #ifdef CONFIG_RT_GROUP_SCHED
> 		if (!sched_rt_can_attach(css_tg(css), task))
> 			return -EINVAL;
> #else
> 		
>
>
>
> */* We don't support RT-tasks being in separate groups */		if (task->sched_class != &fair_sched_class)		{			return -EINVAL;		}*
> #endif
> 	}
> 	return 0;
> }
>
> My question is why is this check required? Also, changing cgroups first and then the policy of FIFO works without issue(?) for the task.
>
> Thanks
>
>
> br
>
> rb
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20160920/e5388bf7/attachment-0001.html