2021-03-26 20:55:06 +03:00
// SPDX-License-Identifier: GPL-2.0-only
/*
* A simple wrapper around refcount . An allocated sched_core_cookie ' s
* address is used to compute the cookie of the task .
*/
struct sched_core_cookie {
refcount_t refcnt ;
} ;
2021-09-22 11:57:35 +03:00
static unsigned long sched_core_alloc_cookie ( void )
2021-03-26 20:55:06 +03:00
{
struct sched_core_cookie * ck = kmalloc ( sizeof ( * ck ) , GFP_KERNEL ) ;
if ( ! ck )
return 0 ;
refcount_set ( & ck - > refcnt , 1 ) ;
sched_core_get ( ) ;
return ( unsigned long ) ck ;
}
2021-09-22 11:57:35 +03:00
static void sched_core_put_cookie ( unsigned long cookie )
2021-03-26 20:55:06 +03:00
{
struct sched_core_cookie * ptr = ( void * ) cookie ;
if ( ptr & & refcount_dec_and_test ( & ptr - > refcnt ) ) {
kfree ( ptr ) ;
sched_core_put ( ) ;
}
}
2021-09-22 11:57:35 +03:00
static unsigned long sched_core_get_cookie ( unsigned long cookie )
2021-03-26 20:55:06 +03:00
{
struct sched_core_cookie * ptr = ( void * ) cookie ;
if ( ptr )
refcount_inc ( & ptr - > refcnt ) ;
return cookie ;
}
/*
* sched_core_update_cookie - replace the cookie on a task
* @ p : the task to update
* @ cookie : the new cookie
*
* Effectively exchange the task cookie ; caller is responsible for lifetimes on
* both ends .
*
* Returns : the old cookie
*/
2021-09-22 11:57:35 +03:00
static unsigned long sched_core_update_cookie ( struct task_struct * p ,
unsigned long cookie )
2021-03-26 20:55:06 +03:00
{
unsigned long old_cookie ;
struct rq_flags rf ;
struct rq * rq ;
rq = task_rq_lock ( p , & rf ) ;
/*
* Since creating a cookie implies sched_core_get ( ) , and we cannot set
* a cookie until after we ' ve created it , similarly , we cannot destroy
* a cookie until after we ' ve removed it , we must have core scheduling
* enabled here .
*/
SCHED_WARN_ON ( ( p - > core_cookie | | cookie ) & & ! sched_core_enabled ( rq ) ) ;
sched/core: Fix the bug that task won't enqueue into core tree when update cookie
In function sched_core_update_cookie(), a task will enqueue into the
core tree only when it enqueued before, that is, if an uncookied task
is cookied, it will not enqueue into the core tree until it enqueue
again, which will result in unnecessary force idle.
Here follows the scenario:
CPU x and CPU y are a pair of SMT siblings.
1. Start task a running on CPU x without sleeping, and task b and
task c running on CPU y without sleeping.
2. We create a cookie and share it to task a and task b, and then
we create another cookie and share it to task c.
3. Simpling core_forceidle_sum of task a and b from /proc/PID/sched
And we will find out that core_forceidle_sum of task a takes 30%
time of the sampling period, which shouldn't happen as task a and b
have the same cookie.
Then we migrate task a to CPU x', migrate task b and c to CPU y', where
CPU x' and CPU y' are a pair of SMT siblings, and sampling again, we
will found out that core_forceidle_sum of task a and b are almost zero.
To solve this problem, we enqueue the task into the core tree if it's
on rq.
Fixes: 6e33cad0af49("sched: Trivial core scheduling cookie management")
Signed-off-by: Cruz Zhao <CruzZhao@linux.alibaba.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/1656403045-100840-2-git-send-email-CruzZhao@linux.alibaba.com
2022-06-28 10:57:23 +03:00
if ( sched_core_enqueued ( p ) )
2021-10-18 23:34:28 +03:00
sched_core_dequeue ( rq , p , DEQUEUE_SAVE ) ;
2021-03-26 20:55:06 +03:00
old_cookie = p - > core_cookie ;
p - > core_cookie = cookie ;
sched/core: Fix the bug that task won't enqueue into core tree when update cookie
In function sched_core_update_cookie(), a task will enqueue into the
core tree only when it enqueued before, that is, if an uncookied task
is cookied, it will not enqueue into the core tree until it enqueue
again, which will result in unnecessary force idle.
Here follows the scenario:
CPU x and CPU y are a pair of SMT siblings.
1. Start task a running on CPU x without sleeping, and task b and
task c running on CPU y without sleeping.
2. We create a cookie and share it to task a and task b, and then
we create another cookie and share it to task c.
3. Simpling core_forceidle_sum of task a and b from /proc/PID/sched
And we will find out that core_forceidle_sum of task a takes 30%
time of the sampling period, which shouldn't happen as task a and b
have the same cookie.
Then we migrate task a to CPU x', migrate task b and c to CPU y', where
CPU x' and CPU y' are a pair of SMT siblings, and sampling again, we
will found out that core_forceidle_sum of task a and b are almost zero.
To solve this problem, we enqueue the task into the core tree if it's
on rq.
Fixes: 6e33cad0af49("sched: Trivial core scheduling cookie management")
Signed-off-by: Cruz Zhao <CruzZhao@linux.alibaba.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lkml.kernel.org/r/1656403045-100840-2-git-send-email-CruzZhao@linux.alibaba.com
2022-06-28 10:57:23 +03:00
/*
* Consider the cases : ! prev_cookie and ! cookie .
*/
if ( cookie & & task_on_rq_queued ( p ) )
2021-03-26 20:55:06 +03:00
sched_core_enqueue ( rq , p ) ;
/*
* If task is currently running , it may not be compatible anymore after
* the cookie change , so enter the scheduler on its CPU to schedule it
* away .
2021-10-18 23:34:28 +03:00
*
* Note that it is possible that as a result of this cookie change , the
* core has now entered / left forced idle state . Defer accounting to the
* next scheduling edge , rather than always forcing a reschedule here .
2021-03-26 20:55:06 +03:00
*/
2022-09-06 13:33:04 +03:00
if ( task_on_cpu ( rq , p ) )
2021-03-26 20:55:06 +03:00
resched_curr ( rq ) ;
task_rq_unlock ( rq , p , & rf ) ;
return old_cookie ;
}
static unsigned long sched_core_clone_cookie ( struct task_struct * p )
{
unsigned long cookie , flags ;
raw_spin_lock_irqsave ( & p - > pi_lock , flags ) ;
cookie = sched_core_get_cookie ( p - > core_cookie ) ;
raw_spin_unlock_irqrestore ( & p - > pi_lock , flags ) ;
return cookie ;
}
2021-03-29 16:18:35 +03:00
void sched_core_fork ( struct task_struct * p )
{
RB_CLEAR_NODE ( & p - > core_node ) ;
p - > core_cookie = sched_core_clone_cookie ( current ) ;
}
2021-03-26 20:55:06 +03:00
void sched_core_free ( struct task_struct * p )
{
sched_core_put_cookie ( p - > core_cookie ) ;
}
sched: prctl() core-scheduling interface
This patch provides support for setting and copying core scheduling
'task cookies' between threads (PID), processes (TGID), and process
groups (PGID).
The value of core scheduling isn't that tasks don't share a core,
'nosmt' can do that. The value lies in exploiting all the sharing
opportunities that exist to recover possible lost performance and that
requires a degree of flexibility in the API.
From a security perspective (and there are others), the thread,
process and process group distinction is an existent hierarchal
categorization of tasks that reflects many of the security concerns
about 'data sharing'. For example, protecting against cache-snooping
by a thread that can just read the memory directly isn't all that
useful.
With this in mind, subcommands to CREATE/SHARE (TO/FROM) provide a
mechanism to create and share cookies. CREATE/SHARE_TO specify a
target pid with enum pidtype used to specify the scope of the targeted
tasks. For example, PIDTYPE_TGID will share the cookie with the
process and all of it's threads as typically desired in a security
scenario.
API:
prctl(PR_SCHED_CORE, PR_SCHED_CORE_GET, tgtpid, pidtype, &cookie)
prctl(PR_SCHED_CORE, PR_SCHED_CORE_CREATE, tgtpid, pidtype, NULL)
prctl(PR_SCHED_CORE, PR_SCHED_CORE_SHARE_TO, tgtpid, pidtype, NULL)
prctl(PR_SCHED_CORE, PR_SCHED_CORE_SHARE_FROM, srcpid, pidtype, NULL)
where 'tgtpid/srcpid == 0' implies the current process and pidtype is
kernel enum pid_type {PIDTYPE_PID, PIDTYPE_TGID, PIDTYPE_PGID, ...}.
For return values, EINVAL, ENOMEM are what they say. ESRCH means the
tgtpid/srcpid was not found. EPERM indicates lack of PTRACE permission
access to tgtpid/srcpid. ENODEV indicates your machines lacks SMT.
[peterz: complete rewrite]
Signed-off-by: Chris Hyser <chris.hyser@oracle.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Tested-by: Don Hiatt <dhiatt@digitalocean.com>
Tested-by: Hongyu Ning <hongyu.ning@linux.intel.com>
Tested-by: Vincent Guittot <vincent.guittot@linaro.org>
Link: https://lkml.kernel.org/r/20210422123309.039845339@infradead.org
2021-03-25 00:40:15 +03:00
static void __sched_core_set ( struct task_struct * p , unsigned long cookie )
{
cookie = sched_core_get_cookie ( cookie ) ;
cookie = sched_core_update_cookie ( p , cookie ) ;
sched_core_put_cookie ( cookie ) ;
}
/* Called from prctl interface: PR_SCHED_CORE */
int sched_core_share_pid ( unsigned int cmd , pid_t pid , enum pid_type type ,
unsigned long uaddr )
{
unsigned long cookie = 0 , id = 0 ;
struct task_struct * task , * p ;
struct pid * grp ;
int err = 0 ;
if ( ! static_branch_likely ( & sched_smt_present ) )
return - ENODEV ;
2021-08-25 20:06:13 +03:00
BUILD_BUG_ON ( PR_SCHED_CORE_SCOPE_THREAD ! = PIDTYPE_PID ) ;
BUILD_BUG_ON ( PR_SCHED_CORE_SCOPE_THREAD_GROUP ! = PIDTYPE_TGID ) ;
BUILD_BUG_ON ( PR_SCHED_CORE_SCOPE_PROCESS_GROUP ! = PIDTYPE_PGID ) ;
sched: prctl() core-scheduling interface
This patch provides support for setting and copying core scheduling
'task cookies' between threads (PID), processes (TGID), and process
groups (PGID).
The value of core scheduling isn't that tasks don't share a core,
'nosmt' can do that. The value lies in exploiting all the sharing
opportunities that exist to recover possible lost performance and that
requires a degree of flexibility in the API.
From a security perspective (and there are others), the thread,
process and process group distinction is an existent hierarchal
categorization of tasks that reflects many of the security concerns
about 'data sharing'. For example, protecting against cache-snooping
by a thread that can just read the memory directly isn't all that
useful.
With this in mind, subcommands to CREATE/SHARE (TO/FROM) provide a
mechanism to create and share cookies. CREATE/SHARE_TO specify a
target pid with enum pidtype used to specify the scope of the targeted
tasks. For example, PIDTYPE_TGID will share the cookie with the
process and all of it's threads as typically desired in a security
scenario.
API:
prctl(PR_SCHED_CORE, PR_SCHED_CORE_GET, tgtpid, pidtype, &cookie)
prctl(PR_SCHED_CORE, PR_SCHED_CORE_CREATE, tgtpid, pidtype, NULL)
prctl(PR_SCHED_CORE, PR_SCHED_CORE_SHARE_TO, tgtpid, pidtype, NULL)
prctl(PR_SCHED_CORE, PR_SCHED_CORE_SHARE_FROM, srcpid, pidtype, NULL)
where 'tgtpid/srcpid == 0' implies the current process and pidtype is
kernel enum pid_type {PIDTYPE_PID, PIDTYPE_TGID, PIDTYPE_PGID, ...}.
For return values, EINVAL, ENOMEM are what they say. ESRCH means the
tgtpid/srcpid was not found. EPERM indicates lack of PTRACE permission
access to tgtpid/srcpid. ENODEV indicates your machines lacks SMT.
[peterz: complete rewrite]
Signed-off-by: Chris Hyser <chris.hyser@oracle.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Tested-by: Don Hiatt <dhiatt@digitalocean.com>
Tested-by: Hongyu Ning <hongyu.ning@linux.intel.com>
Tested-by: Vincent Guittot <vincent.guittot@linaro.org>
Link: https://lkml.kernel.org/r/20210422123309.039845339@infradead.org
2021-03-25 00:40:15 +03:00
if ( type > PIDTYPE_PGID | | cmd > = PR_SCHED_CORE_MAX | | pid < 0 | |
( cmd ! = PR_SCHED_CORE_GET & & uaddr ) )
return - EINVAL ;
rcu_read_lock ( ) ;
if ( pid = = 0 ) {
task = current ;
} else {
task = find_task_by_vpid ( pid ) ;
if ( ! task ) {
rcu_read_unlock ( ) ;
return - ESRCH ;
}
}
get_task_struct ( task ) ;
rcu_read_unlock ( ) ;
/*
* Check if this process has the right to modify the specified
* process . Use the regular " ptrace_may_access() " checks .
*/
if ( ! ptrace_may_access ( task , PTRACE_MODE_READ_REALCREDS ) ) {
err = - EPERM ;
goto out ;
}
switch ( cmd ) {
case PR_SCHED_CORE_GET :
if ( type ! = PIDTYPE_PID | | uaddr & 7 ) {
err = - EINVAL ;
goto out ;
}
cookie = sched_core_clone_cookie ( task ) ;
if ( cookie ) {
/* XXX improve ? */
ptr_to_hashval ( ( void * ) cookie , & id ) ;
}
err = put_user ( id , ( u64 __user * ) uaddr ) ;
goto out ;
case PR_SCHED_CORE_CREATE :
cookie = sched_core_alloc_cookie ( ) ;
if ( ! cookie ) {
err = - ENOMEM ;
goto out ;
}
break ;
case PR_SCHED_CORE_SHARE_TO :
cookie = sched_core_clone_cookie ( current ) ;
break ;
case PR_SCHED_CORE_SHARE_FROM :
if ( type ! = PIDTYPE_PID ) {
err = - EINVAL ;
goto out ;
}
cookie = sched_core_clone_cookie ( task ) ;
__sched_core_set ( current , cookie ) ;
goto out ;
default :
err = - EINVAL ;
goto out ;
2022-07-19 14:10:44 +03:00
}
sched: prctl() core-scheduling interface
This patch provides support for setting and copying core scheduling
'task cookies' between threads (PID), processes (TGID), and process
groups (PGID).
The value of core scheduling isn't that tasks don't share a core,
'nosmt' can do that. The value lies in exploiting all the sharing
opportunities that exist to recover possible lost performance and that
requires a degree of flexibility in the API.
From a security perspective (and there are others), the thread,
process and process group distinction is an existent hierarchal
categorization of tasks that reflects many of the security concerns
about 'data sharing'. For example, protecting against cache-snooping
by a thread that can just read the memory directly isn't all that
useful.
With this in mind, subcommands to CREATE/SHARE (TO/FROM) provide a
mechanism to create and share cookies. CREATE/SHARE_TO specify a
target pid with enum pidtype used to specify the scope of the targeted
tasks. For example, PIDTYPE_TGID will share the cookie with the
process and all of it's threads as typically desired in a security
scenario.
API:
prctl(PR_SCHED_CORE, PR_SCHED_CORE_GET, tgtpid, pidtype, &cookie)
prctl(PR_SCHED_CORE, PR_SCHED_CORE_CREATE, tgtpid, pidtype, NULL)
prctl(PR_SCHED_CORE, PR_SCHED_CORE_SHARE_TO, tgtpid, pidtype, NULL)
prctl(PR_SCHED_CORE, PR_SCHED_CORE_SHARE_FROM, srcpid, pidtype, NULL)
where 'tgtpid/srcpid == 0' implies the current process and pidtype is
kernel enum pid_type {PIDTYPE_PID, PIDTYPE_TGID, PIDTYPE_PGID, ...}.
For return values, EINVAL, ENOMEM are what they say. ESRCH means the
tgtpid/srcpid was not found. EPERM indicates lack of PTRACE permission
access to tgtpid/srcpid. ENODEV indicates your machines lacks SMT.
[peterz: complete rewrite]
Signed-off-by: Chris Hyser <chris.hyser@oracle.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Tested-by: Don Hiatt <dhiatt@digitalocean.com>
Tested-by: Hongyu Ning <hongyu.ning@linux.intel.com>
Tested-by: Vincent Guittot <vincent.guittot@linaro.org>
Link: https://lkml.kernel.org/r/20210422123309.039845339@infradead.org
2021-03-25 00:40:15 +03:00
if ( type = = PIDTYPE_PID ) {
__sched_core_set ( task , cookie ) ;
goto out ;
}
read_lock ( & tasklist_lock ) ;
grp = task_pid_type ( task , type ) ;
do_each_pid_thread ( grp , type , p ) {
if ( ! ptrace_may_access ( p , PTRACE_MODE_READ_REALCREDS ) ) {
err = - EPERM ;
goto out_tasklist ;
}
} while_each_pid_thread ( grp , type , p ) ;
do_each_pid_thread ( grp , type , p ) {
__sched_core_set ( p , cookie ) ;
} while_each_pid_thread ( grp , type , p ) ;
out_tasklist :
read_unlock ( & tasklist_lock ) ;
out :
sched_core_put_cookie ( cookie ) ;
put_task_struct ( task ) ;
return err ;
}
2021-10-18 23:34:28 +03:00
# ifdef CONFIG_SCHEDSTATS
/* REQUIRES: rq->core's clock recently updated. */
void __sched_core_account_forceidle ( struct rq * rq )
{
const struct cpumask * smt_mask = cpu_smt_mask ( cpu_of ( rq ) ) ;
u64 delta , now = rq_clock ( rq - > core ) ;
struct rq * rq_i ;
struct task_struct * p ;
int i ;
lockdep_assert_rq_held ( rq ) ;
WARN_ON_ONCE ( ! rq - > core - > core_forceidle_count ) ;
if ( rq - > core - > core_forceidle_start = = 0 )
return ;
delta = now - rq - > core - > core_forceidle_start ;
if ( unlikely ( ( s64 ) delta < = 0 ) )
return ;
rq - > core - > core_forceidle_start = now ;
if ( WARN_ON_ONCE ( ! rq - > core - > core_forceidle_occupation ) ) {
/* can't be forced idle without a running task */
} else if ( rq - > core - > core_forceidle_count > 1 | |
rq - > core - > core_forceidle_occupation > 1 ) {
/*
* For larger SMT configurations , we need to scale the charged
* forced idle amount since there can be more than one forced
* idle sibling and more than one running cookied task .
*/
delta * = rq - > core - > core_forceidle_count ;
delta = div_u64 ( delta , rq - > core - > core_forceidle_occupation ) ;
}
for_each_cpu ( i , smt_mask ) {
rq_i = cpu_rq ( i ) ;
p = rq_i - > core_pick ? : rq_i - > curr ;
sched/core: Accounting forceidle time for all tasks except idle task
There are two types of forced idle time: forced idle time from cookie'd
task and forced idle time form uncookie'd task. The forced idle time from
uncookie'd task is actually caused by the cookie'd task in runqueue
indirectly, and it's more accurate to measure the capacity loss with the
sum of both.
Assuming cpu x and cpu y are a pair of SMT siblings, consider the
following scenarios:
1.There's a cookie'd task running on cpu x, and there're 4 uncookie'd
tasks running on cpu y. For cpu x, there will be 80% forced idle time
(from uncookie'd task); for cpu y, there will be 20% forced idle time
(from cookie'd task).
2.There's a uncookie'd task running on cpu x, and there're 4 cookie'd
tasks running on cpu y. For cpu x, there will be 80% forced idle time
(from cookie'd task); for cpu y, there will be 20% forced idle time
(from uncookie'd task).
The scenario1 can recurrent by stress-ng(scenario2 can recurrent similary):
(cookie'd)taskset -c x stress-ng -c 1 -l 100
(uncookie'd)taskset -c y stress-ng -c 4 -l 100
In the above two scenarios, the total capacity loss is 1 cpu, but in
scenario1, the cookie'd forced idle time tells us 20% cpu capacity loss, in
scenario2, the cookie'd forced idle time tells us 80% cpu capacity loss,
which are not accurate. It'll be more accurate to measure with cookie'd
forced idle time and uncookie'd forced idle time.
Signed-off-by: Cruz Zhao <CruzZhao@linux.alibaba.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Josh Don <joshdon@google.com>
Link: https://lore.kernel.org/r/1641894961-9241-2-git-send-email-CruzZhao@linux.alibaba.com
2022-01-11 12:55:59 +03:00
if ( p = = rq_i - > idle )
2021-10-18 23:34:28 +03:00
continue ;
2022-06-30 00:14:26 +03:00
/*
* Note : this will account forceidle to the current cpu , even
* if it comes from our SMT sibling .
*/
__account_forceidle_time ( p , delta ) ;
2021-10-18 23:34:28 +03:00
}
}
void __sched_core_tick ( struct rq * rq )
{
if ( ! rq - > core - > core_forceidle_count )
return ;
if ( rq ! = rq - > core )
update_rq_clock ( rq - > core ) ;
__sched_core_account_forceidle ( rq ) ;
}
# endif /* CONFIG_SCHEDSTATS */