diff mbox series

sched: Filter root_task_group at the beginning

Message ID 20230922094336.394865-1-haifeng.xu@shopee.com
State New
Headers
Series sched: Filter root_task_group at the beginning |

Commit Message

Haifeng Xu Sept. 22, 2023, 9:43 a.m. UTC 
  We can't change the weight of the root cgroup. Let's handle
root_task_group before doing any real work including acquiring
the shares_mutex.

Signed-off-by: Haifeng Xu <haifeng.xu@shopee.com>
---
 kernel/sched/fair.c | 3 +++
 1 file changed, 3 insertions(+)

Comments

Ingo Molnar Sept. 28, 2023, 9:03 p.m. UTC | #1 
* Haifeng Xu <haifeng.xu@shopee.com> wrote:

> We can't change the weight of the root cgroup. Let's handle
> root_task_group before doing any real work including acquiring
> the shares_mutex.
> 
> Signed-off-by: Haifeng Xu <haifeng.xu@shopee.com>
> ---
>  kernel/sched/fair.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index a80a73909dc2..1ac2df87e070 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -12594,6 +12594,9 @@ int sched_group_set_shares(struct task_group *tg, unsigned long shares)
>  {
>  	int ret;
>  
> +	if (tg == &root_task_group)
> +		return -EINVAL;
> +
>  	mutex_lock(&shares_mutex);
>  	if (tg_is_idle(tg))
>  		ret = -EINVAL;

So what's the motivation, how common is this case? 

Normally this should be a -EINVAL error code path, which sane user-space
presumably never conscisously tries to call in that fashion, right?

It's not worth optimizing pathological cases, especially
since we check for the root CG inside __sched_group_set_shares()
already:

        /*
         * We can't change the weight of the root cgroup.
         */
        if (!tg->se[0])
                return -EINVAL;


Thanks,

	Ingo
Haifeng Xu Sept. 29, 2023, 11:56 a.m. UTC | #2 
On 2023/9/29 05:03, Ingo Molnar wrote:
> 
> * Haifeng Xu <haifeng.xu@shopee.com> wrote:
> 
>> We can't change the weight of the root cgroup. Let's handle
>> root_task_group before doing any real work including acquiring
>> the shares_mutex.
>>
>> Signed-off-by: Haifeng Xu <haifeng.xu@shopee.com>
>> ---
>>  kernel/sched/fair.c | 3 +++
>>  1 file changed, 3 insertions(+)
>>
>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>> index a80a73909dc2..1ac2df87e070 100644
>> --- a/kernel/sched/fair.c
>> +++ b/kernel/sched/fair.c
>> @@ -12594,6 +12594,9 @@ int sched_group_set_shares(struct task_group *tg, unsigned long shares)
>>  {
>>  	int ret;
>>  
>> +	if (tg == &root_task_group)
>> +		return -EINVAL;
>> +
>>  	mutex_lock(&shares_mutex);
>>  	if (tg_is_idle(tg))
>>  		ret = -EINVAL;
> 
> So what's the motivation, how common is this case? 

It's not common.

The users of __sched_group_set_shares() are sched_group_set_idle() and sched_group_set_shares().
So I want to follow the way in sched_group_set_idle(). If so, we can remove the redundant checks in
__sched_group_set_shares() because all users have filtered the root_task_group.

> 
> Normally this should be a -EINVAL error code path, which sane user-space
> presumably never conscisously tries to call in that fashion, right?

Yes.

> 
> It's not worth optimizing pathological cases, especially
> since we check for the root CG inside __sched_group_set_shares()
> already:
> 
>         /*
>          * We can't change the weight of the root cgroup.
>          */
>         if (!tg->se[0])
>                 return -EINVAL;
> 
> 
> Thanks,
> 
> 	Ingo
diff mbox series

Patch

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index a80a73909dc2..1ac2df87e070 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -12594,6 +12594,9 @@  int sched_group_set_shares(struct task_group *tg, unsigned long shares)
 {
 	int ret;
 
+	if (tg == &root_task_group)
+		return -EINVAL;
+
 	mutex_lock(&shares_mutex);
 	if (tg_is_idle(tg))
 		ret = -EINVAL;