Re: [RFC PATCH 09/18] kthread: Make it easier to correctly sleep in iterant kthreads
On Wed, 10 Jun 2015, Steven Rostedt wrote: > > Right, and I had not considered that, but it turns out the hung_task > > detector checks p->state == TASK_UNINTERRUPTIBLE, so TASK_IDLE is indeed > > safe from that. > > Also, I would assume that TASK_IDLE only makes sense for kernel > threads, I wonder if we should add an assertion in schedule that > triggers if a task is scheduling with TASK_IDLE and is not a kernel > thread (has its own mm?) For the sake of completnes -- testing for !task_struct->mm is not a correct test to find out whether given entity is a kernel thread; kernel threads are free to temporarily adopt user struct mm via use_mm() (usually for handling AIO on behalf of a particular struct mm). The correct check is to look at PF_KTHREAD flag in task_struct->flags. -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 09/18] kthread: Make it easier to correctly sleep in iterant kthreads
On Wed, 10 Jun 2015 11:07:24 +0200 Peter Zijlstra wrote: > > Not to mention, tasks in TASK_UNINTERRUPTIBLE state for too long will > > trigger hung task detection. > > Right, and I had not considered that, but it turns out the hung_task > detector checks p->state == TASK_UNINTERRUPTIBLE, so TASK_IDLE is indeed > safe from that. Also, I would assume that TASK_IDLE only makes sense for kernel threads, I wonder if we should add an assertion in schedule that triggers if a task is scheduling with TASK_IDLE and is not a kernel thread (has its own mm?) -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 09/18] kthread: Make it easier to correctly sleep in iterant kthreads
On Mon, Jun 08, 2015 at 01:48:10PM -0400, Steven Rostedt wrote: > > commit 80ed87c8a9ca0cad7ca66cf3bbdfb17559a66dcf > > Author: Peter Zijlstra > > Date: Fri May 8 14:23:45 2015 +0200 > > > > sched/wait: Introduce TASK_NOLOAD and TASK_IDLE > > > > Currently people use TASK_INTERRUPTIBLE to idle kthreads and wait for > > 'work' because TASK_UNINTERRUPTIBLE contributes to the loadavg. Having > > all idle kthreads contribute to the loadavg is somewhat silly. > > Not to mention, tasks in TASK_UNINTERRUPTIBLE state for too long will > trigger hung task detection. Right, and I had not considered that, but it turns out the hung_task detector checks p->state == TASK_UNINTERRUPTIBLE, so TASK_IDLE is indeed safe from that. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 09/18] kthread: Make it easier to correctly sleep in iterant kthreads
On Tue, Jun 09, 2015 at 05:25:26PM +0200, Petr Mladek wrote:
> On Mon 2015-06-08 13:39:55, Peter Zijlstra wrote:
> > On Mon, 2015-06-08 at 12:01 +0200, Petr Mladek wrote:
> >
> > > Just to be sure. Do you suggest to use TASK_IDLE everywhere in
> > > kthreads or only when the uninterruptible sleep is really needed?
> >
> > Always, only use INTERRUPTIBLE when you're actually interruptible, that
> > is you want signals or such muck to terminate your wait.
>
> I like that TASK_IDLE clearly describes that the state of the task.
> I am just curious. Is there any particular advantage of using
> uninterruptible sleep over the interruptible one, please?
I think, given how all schedule() calls should be inside a loop testing
their sleep condition, and one has to assume spurious wakeups anyhow,
one can make an argument for removing the distinction.
That said, typically INTERRUPTIBLE means 'capable of handling signals
while waiting for $foo', and as said elsewhere in this thread, kthreads
should not really be having signals.
In that spirit, I think UNINTERRUPTIBLE is the right sleep.
> I ask because making freezable kthreads is quite tricky. You need to
> call try_to_freeze() after each schedule or call freezable_* variants
> of schedule(). I think that it is easy to make a mistake. I wonder if
> it might be more elegant to use interruptible sleep whenever possible,
> send the fake signal also to kthreads and force them moving into some
> location where the freeze is safe and handled.
I don't think that's really a concern here, you have an absolutely
perfect freeze point and freezable_schedule() is fine.
>
> > > IMHO, we should not use TASK_IDLE in freezable kthreads because
> > > it would break freezing.
> >
> > How so? The task is IDLE, its not doing anything.
>
> Well, it might cause the freeze. I have just double checked this
> with ubi_thread(). It calls set_freezable().
> I did the following change:
>
> diff --git a/drivers/mtd/ubi/wl.c b/drivers/mtd/ubi/wl.c
> index 16214d3d57a4..d528fa5e93ba 100644
> --- a/drivers/mtd/ubi/wl.c
> +++ b/drivers/mtd/ubi/wl.c
> @@ -1428,7 +1428,7 @@ int ubi_thread(void *u)
> spin_lock(>wl_lock);
> if (list_empty(>works) || ubi->ro_mode ||
> !ubi->thread_enabled || ubi_dbg_is_bgt_disabled(ubi)) {
> - set_current_state(TASK_INTERRUPTIBLE);
> + set_current_state(TASK_IDLE);
> spin_unlock(>wl_lock);
> schedule();
> continue;
> or use in ubi_thread()
>
> freezable_schedule()
This
> or always ignore freezing when the task sets TASK_IDLE.
Can't, because they might get woken up, in which case they need to end
up in the fridge.
> > And this is the arch typical freeze point if ever there was one, you're
> > checking kthread_stop, if we can terminate the kthread, we can certainly
> > get frozen.
>
> It makes sense. The tasks should be in some sane state when it goes
> into the idle state. I hope that people will not misuse it too much.
Do your utmost bestest to put in as many assertions as you can to avoid
abuse.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 09/18] kthread: Make it easier to correctly sleep in iterant kthreads
On Tue, Jun 09, 2015 at 05:25:26PM +0200, Petr Mladek wrote:
On Mon 2015-06-08 13:39:55, Peter Zijlstra wrote:
On Mon, 2015-06-08 at 12:01 +0200, Petr Mladek wrote:
Just to be sure. Do you suggest to use TASK_IDLE everywhere in
kthreads or only when the uninterruptible sleep is really needed?
Always, only use INTERRUPTIBLE when you're actually interruptible, that
is you want signals or such muck to terminate your wait.
I like that TASK_IDLE clearly describes that the state of the task.
I am just curious. Is there any particular advantage of using
uninterruptible sleep over the interruptible one, please?
I think, given how all schedule() calls should be inside a loop testing
their sleep condition, and one has to assume spurious wakeups anyhow,
one can make an argument for removing the distinction.
That said, typically INTERRUPTIBLE means 'capable of handling signals
while waiting for $foo', and as said elsewhere in this thread, kthreads
should not really be having signals.
In that spirit, I think UNINTERRUPTIBLE is the right sleep.
I ask because making freezable kthreads is quite tricky. You need to
call try_to_freeze() after each schedule or call freezable_* variants
of schedule(). I think that it is easy to make a mistake. I wonder if
it might be more elegant to use interruptible sleep whenever possible,
send the fake signal also to kthreads and force them moving into some
location where the freeze is safe and handled.
I don't think that's really a concern here, you have an absolutely
perfect freeze point and freezable_schedule() is fine.
IMHO, we should not use TASK_IDLE in freezable kthreads because
it would break freezing.
How so? The task is IDLE, its not doing anything.
Well, it might cause the freeze. I have just double checked this
with ubi_thread(). It calls set_freezable().
I did the following change:
diff --git a/drivers/mtd/ubi/wl.c b/drivers/mtd/ubi/wl.c
index 16214d3d57a4..d528fa5e93ba 100644
--- a/drivers/mtd/ubi/wl.c
+++ b/drivers/mtd/ubi/wl.c
@@ -1428,7 +1428,7 @@ int ubi_thread(void *u)
spin_lock(ubi-wl_lock);
if (list_empty(ubi-works) || ubi-ro_mode ||
!ubi-thread_enabled || ubi_dbg_is_bgt_disabled(ubi)) {
- set_current_state(TASK_INTERRUPTIBLE);
+ set_current_state(TASK_IDLE);
spin_unlock(ubi-wl_lock);
schedule();
continue;
or use in ubi_thread()
freezable_schedule()
This
or always ignore freezing when the task sets TASK_IDLE.
Can't, because they might get woken up, in which case they need to end
up in the fridge.
And this is the arch typical freeze point if ever there was one, you're
checking kthread_stop, if we can terminate the kthread, we can certainly
get frozen.
It makes sense. The tasks should be in some sane state when it goes
into the idle state. I hope that people will not misuse it too much.
Do your utmost bestest to put in as many assertions as you can to avoid
abuse.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 09/18] kthread: Make it easier to correctly sleep in iterant kthreads
On Mon, Jun 08, 2015 at 01:48:10PM -0400, Steven Rostedt wrote: commit 80ed87c8a9ca0cad7ca66cf3bbdfb17559a66dcf Author: Peter Zijlstra pet...@infradead.org Date: Fri May 8 14:23:45 2015 +0200 sched/wait: Introduce TASK_NOLOAD and TASK_IDLE Currently people use TASK_INTERRUPTIBLE to idle kthreads and wait for 'work' because TASK_UNINTERRUPTIBLE contributes to the loadavg. Having all idle kthreads contribute to the loadavg is somewhat silly. Not to mention, tasks in TASK_UNINTERRUPTIBLE state for too long will trigger hung task detection. Right, and I had not considered that, but it turns out the hung_task detector checks p-state == TASK_UNINTERRUPTIBLE, so TASK_IDLE is indeed safe from that. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 09/18] kthread: Make it easier to correctly sleep in iterant kthreads
On Wed, 10 Jun 2015 11:07:24 +0200 Peter Zijlstra pet...@infradead.org wrote: Not to mention, tasks in TASK_UNINTERRUPTIBLE state for too long will trigger hung task detection. Right, and I had not considered that, but it turns out the hung_task detector checks p-state == TASK_UNINTERRUPTIBLE, so TASK_IDLE is indeed safe from that. Also, I would assume that TASK_IDLE only makes sense for kernel threads, I wonder if we should add an assertion in schedule that triggers if a task is scheduling with TASK_IDLE and is not a kernel thread (has its own mm?) -- Steve -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 09/18] kthread: Make it easier to correctly sleep in iterant kthreads
On Wed, 10 Jun 2015, Steven Rostedt wrote: Right, and I had not considered that, but it turns out the hung_task detector checks p-state == TASK_UNINTERRUPTIBLE, so TASK_IDLE is indeed safe from that. Also, I would assume that TASK_IDLE only makes sense for kernel threads, I wonder if we should add an assertion in schedule that triggers if a task is scheduling with TASK_IDLE and is not a kernel thread (has its own mm?) For the sake of completnes -- testing for !task_struct-mm is not a correct test to find out whether given entity is a kernel thread; kernel threads are free to temporarily adopt user struct mm via use_mm() (usually for handling AIO on behalf of a particular struct mm). The correct check is to look at PF_KTHREAD flag in task_struct-flags. -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 09/18] kthread: Make it easier to correctly sleep in iterant kthreads
On Mon 2015-06-08 13:39:55, Peter Zijlstra wrote:
> On Mon, 2015-06-08 at 12:01 +0200, Petr Mladek wrote:
>
> > Just to be sure. Do you suggest to use TASK_IDLE everywhere in
> > kthreads or only when the uninterruptible sleep is really needed?
>
> Always, only use INTERRUPTIBLE when you're actually interruptible, that
> is you want signals or such muck to terminate your wait.
I like that TASK_IDLE clearly describes that the state of the task.
I am just curious. Is there any particular advantage of using
uninterruptible sleep over the interruptible one, please?
I ask because making freezable kthreads is quite tricky. You need to
call try_to_freeze() after each schedule or call freezable_* variants
of schedule(). I think that it is easy to make a mistake. I wonder if
it might be more elegant to use interruptible sleep whenever possible,
send the fake signal also to kthreads and force them moving into some
location where the freeze is safe and handled.
> > IMHO, we should not use TASK_IDLE in freezable kthreads because
> > it would break freezing.
>
> How so? The task is IDLE, its not doing anything.
Well, it might cause the freeze. I have just double checked this
with ubi_thread(). It calls set_freezable().
I did the following change:
diff --git a/drivers/mtd/ubi/wl.c b/drivers/mtd/ubi/wl.c
index 16214d3d57a4..d528fa5e93ba 100644
--- a/drivers/mtd/ubi/wl.c
+++ b/drivers/mtd/ubi/wl.c
@@ -1428,7 +1428,7 @@ int ubi_thread(void *u)
spin_lock(>wl_lock);
if (list_empty(>works) || ubi->ro_mode ||
!ubi->thread_enabled || ubi_dbg_is_bgt_disabled(ubi)) {
- set_current_state(TASK_INTERRUPTIBLE);
+ set_current_state(TASK_IDLE);
spin_unlock(>wl_lock);
schedule();
continue;
enabled this stuff:
$> grep UBI .config
CONFIG_TCP_CONG_CUBIC=y
CONFIG_DEFAULT_CUBIC=y
CONFIG_MTD_UBI=y
CONFIG_MTD_UBI_WL_THRESHOLD=4096
CONFIG_MTD_UBI_BEB_LIMIT=20
# CONFIG_MTD_UBI_FASTMAP is not set
CONFIG_MTD_UBI_GLUEBI=y
CONFIG_MTD_UBI_BLOCK=y
# CONFIG_JFFS2_RUBIN is not set
CONFIG_UBIFS_FS=y
# CONFIG_UBIFS_FS_ADVANCED_COMPR is not set
CONFIG_UBIFS_FS_LZO=y
CONFIG_UBIFS_FS_ZLIB=y
# CONFIG_CRYPTO_ANUBIS is not set
called on the running system:
$> ubiattach /dev/ubi_ctrl -m 0
to launch "ubi_bgt0d"
and it started to block freezer:
$> echo freezer >/sys/power/pm_test
$> echo reboot >/sys/power/disk
$> echo disk >/sys/power/state
-bash: echo: write error: Device or resource busy
$dmesg
[ 658.874518] Freezing of tasks failed after 20.008 seconds (1 tasks refusing
to freeze, wq_busy=0):
[ 658.874527] ubi_bgt0d D 880136e2be38 0 3107 2 0x
[ 658.874530] 880136e2be38 88013a456410 880133808210
8800b3f5cd00
[ 658.874532] 880136e2c000 880133808210 8800ba1fd15c
8800ba1fd1d8
[ 658.874533] 8800ba1fd1fc 880136e2be58 81905737
8800ba1fd15c
[ 658.874535] Call Trace:
[ 658.874540] [] schedule+0x37/0x90
[ 658.874543] [] ubi_thread+0xd5/0x1f0
[ 658.874545] [] ? ubi_wl_flush+0x1f0/0x1f0
[ 658.874547] [] kthread+0xc9/0xe0
[ 658.874549] [] ? kthread_create_on_node+0x180/0x180
[ 658.874551] [] ret_from_fork+0x42/0x70
[ 658.874552] [] ? kthread_create_on_node+0x180/0x180
[ 658.874554] Restarting kernel threads ... done.
[ 658.892995] PM: Basic memory bitmaps freed
[ 658.892999] Restarting tasks ... done.
It is because freeze_task() tries to wake up inly kthreads in
interruptible state. I does:
wake_up_state(p, TASK_INTERRUPTIBLE);
Solutions would be to try in freeze_task() also
wake_up_state(p, TASK_IDLE);
or use in ubi_thread()
freezable_schedule()
or always ignore freezing when the task sets TASK_IDLE.
> > Well, we could freezable_schedule() but only
> > on locations where it is safe to get freezed. Anyway, we need to
> > be careful here.
>
> Bah, you made me look at the freezer code, karma reduction for you.
I feel like it has happened.
> And this is the arch typical freeze point if ever there was one, you're
> checking kthread_stop, if we can terminate the kthread, we can certainly
> get frozen.
It makes sense. The tasks should be in some sane state when it goes
into the idle state. I hope that people will not misuse it too much.
Best Regards,
Petr
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 09/18] kthread: Make it easier to correctly sleep in iterant kthreads
Hello, On Mon, Jun 08, 2015 at 12:01:07PM +0200, Petr Mladek wrote: > BTW: What is the preferred way of freezing, please? Is it better > to end up in the fridge or is it fine to call freezer_do_not_count(); > or set PF_NOFREEZE when it is safe? There's no one good answer. The closest would be "don't use freezer on kthreads". As Peter said, exit points are always safe freezing points and it's generally a good idea to avoid adding one anywhere else. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 09/18] kthread: Make it easier to correctly sleep in iterant kthreads
Hello, On Mon, Jun 08, 2015 at 12:01:07PM +0200, Petr Mladek wrote: BTW: What is the preferred way of freezing, please? Is it better to end up in the fridge or is it fine to call freezer_do_not_count(); or set PF_NOFREEZE when it is safe? There's no one good answer. The closest would be don't use freezer on kthreads. As Peter said, exit points are always safe freezing points and it's generally a good idea to avoid adding one anywhere else. Thanks. -- tejun -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 09/18] kthread: Make it easier to correctly sleep in iterant kthreads
On Mon 2015-06-08 13:39:55, Peter Zijlstra wrote:
On Mon, 2015-06-08 at 12:01 +0200, Petr Mladek wrote:
Just to be sure. Do you suggest to use TASK_IDLE everywhere in
kthreads or only when the uninterruptible sleep is really needed?
Always, only use INTERRUPTIBLE when you're actually interruptible, that
is you want signals or such muck to terminate your wait.
I like that TASK_IDLE clearly describes that the state of the task.
I am just curious. Is there any particular advantage of using
uninterruptible sleep over the interruptible one, please?
I ask because making freezable kthreads is quite tricky. You need to
call try_to_freeze() after each schedule or call freezable_* variants
of schedule(). I think that it is easy to make a mistake. I wonder if
it might be more elegant to use interruptible sleep whenever possible,
send the fake signal also to kthreads and force them moving into some
location where the freeze is safe and handled.
IMHO, we should not use TASK_IDLE in freezable kthreads because
it would break freezing.
How so? The task is IDLE, its not doing anything.
Well, it might cause the freeze. I have just double checked this
with ubi_thread(). It calls set_freezable().
I did the following change:
diff --git a/drivers/mtd/ubi/wl.c b/drivers/mtd/ubi/wl.c
index 16214d3d57a4..d528fa5e93ba 100644
--- a/drivers/mtd/ubi/wl.c
+++ b/drivers/mtd/ubi/wl.c
@@ -1428,7 +1428,7 @@ int ubi_thread(void *u)
spin_lock(ubi-wl_lock);
if (list_empty(ubi-works) || ubi-ro_mode ||
!ubi-thread_enabled || ubi_dbg_is_bgt_disabled(ubi)) {
- set_current_state(TASK_INTERRUPTIBLE);
+ set_current_state(TASK_IDLE);
spin_unlock(ubi-wl_lock);
schedule();
continue;
enabled this stuff:
$ grep UBI .config
CONFIG_TCP_CONG_CUBIC=y
CONFIG_DEFAULT_CUBIC=y
CONFIG_MTD_UBI=y
CONFIG_MTD_UBI_WL_THRESHOLD=4096
CONFIG_MTD_UBI_BEB_LIMIT=20
# CONFIG_MTD_UBI_FASTMAP is not set
CONFIG_MTD_UBI_GLUEBI=y
CONFIG_MTD_UBI_BLOCK=y
# CONFIG_JFFS2_RUBIN is not set
CONFIG_UBIFS_FS=y
# CONFIG_UBIFS_FS_ADVANCED_COMPR is not set
CONFIG_UBIFS_FS_LZO=y
CONFIG_UBIFS_FS_ZLIB=y
# CONFIG_CRYPTO_ANUBIS is not set
called on the running system:
$ ubiattach /dev/ubi_ctrl -m 0
to launch ubi_bgt0d
and it started to block freezer:
$ echo freezer /sys/power/pm_test
$ echo reboot /sys/power/disk
$ echo disk /sys/power/state
-bash: echo: write error: Device or resource busy
$dmesg
[ 658.874518] Freezing of tasks failed after 20.008 seconds (1 tasks refusing
to freeze, wq_busy=0):
[ 658.874527] ubi_bgt0d D 880136e2be38 0 3107 2 0x
[ 658.874530] 880136e2be38 88013a456410 880133808210
8800b3f5cd00
[ 658.874532] 880136e2c000 880133808210 8800ba1fd15c
8800ba1fd1d8
[ 658.874533] 8800ba1fd1fc 880136e2be58 81905737
8800ba1fd15c
[ 658.874535] Call Trace:
[ 658.874540] [81905737] schedule+0x37/0x90
[ 658.874543] [816b3065] ubi_thread+0xd5/0x1f0
[ 658.874545] [816b2f90] ? ubi_wl_flush+0x1f0/0x1f0
[ 658.874547] [81085219] kthread+0xc9/0xe0
[ 658.874549] [81085150] ? kthread_create_on_node+0x180/0x180
[ 658.874551] [81909962] ret_from_fork+0x42/0x70
[ 658.874552] [81085150] ? kthread_create_on_node+0x180/0x180
[ 658.874554] Restarting kernel threads ... done.
[ 658.892995] PM: Basic memory bitmaps freed
[ 658.892999] Restarting tasks ... done.
It is because freeze_task() tries to wake up inly kthreads in
interruptible state. I does:
wake_up_state(p, TASK_INTERRUPTIBLE);
Solutions would be to try in freeze_task() also
wake_up_state(p, TASK_IDLE);
or use in ubi_thread()
freezable_schedule()
or always ignore freezing when the task sets TASK_IDLE.
Well, we could freezable_schedule() but only
on locations where it is safe to get freezed. Anyway, we need to
be careful here.
Bah, you made me look at the freezer code, karma reduction for you.
I feel like it has happened.
And this is the arch typical freeze point if ever there was one, you're
checking kthread_stop, if we can terminate the kthread, we can certainly
get frozen.
It makes sense. The tasks should be in some sane state when it goes
into the idle state. I hope that people will not misuse it too much.
Best Regards,
Petr
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 09/18] kthread: Make it easier to correctly sleep in iterant kthreads
On Fri, 5 Jun 2015 18:10:21 +0200 Peter Zijlstra wrote: > On Fri, Jun 05, 2015 at 05:01:08PM +0200, Petr Mladek wrote: > > Many kthreads go into an interruptible sleep when there is nothing > > to do. They should check if anyone did not requested the kthread > > to terminate, freeze, or park in the meantime. It is easy to do > > it a wrong way. > > INTERRUPTIBLE is the wrong state to idle in for kthreads, use > TASK_IDLE. > > --- > > commit 80ed87c8a9ca0cad7ca66cf3bbdfb17559a66dcf > Author: Peter Zijlstra > Date: Fri May 8 14:23:45 2015 +0200 > > sched/wait: Introduce TASK_NOLOAD and TASK_IDLE > > Currently people use TASK_INTERRUPTIBLE to idle kthreads and wait for > 'work' because TASK_UNINTERRUPTIBLE contributes to the loadavg. Having > all idle kthreads contribute to the loadavg is somewhat silly. Not to mention, tasks in TASK_UNINTERRUPTIBLE state for too long will trigger hung task detection. > > Now mostly this works OK, because kthreads have all their signals > masked. However there's a few sites where this is causing problems and > TASK_UNINTERRUPTIBLE should be used, except for that loadavg issue. > > This patch adds TASK_NOLOAD which, when combined with > TASK_UNINTERRUPTIBLE avoids the loadavg accounting. > > As most of imagined usage sites are loops where a thread wants to > idle, waiting for work, a helper TASK_IDLE is introduced. > > Signed-off-by: Peter Zijlstra (Intel) Acked-by: Steven Rostedt -- Steve > Cc: Julian Anastasov > Cc: Linus Torvalds > Cc: NeilBrown > Cc: Oleg Nesterov > Cc: Peter Zijlstra > Cc: Thomas Gleixner > Signed-off-by: Ingo Molnar > > diff --git a/include/linux/sched.h b/include/linux/sched.h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 09/18] kthread: Make it easier to correctly sleep in iterant kthreads
On Mon, 2015-06-08 at 12:01 +0200, Petr Mladek wrote: > Just to be sure. Do you suggest to use TASK_IDLE everywhere in > kthreads or only when the uninterruptible sleep is really needed? Always, only use INTERRUPTIBLE when you're actually interruptible, that is you want signals or such muck to terminate your wait. > IMHO, we should not use TASK_IDLE in freezable kthreads because > it would break freezing. How so? The task is IDLE, its not doing anything. > Well, we could freezable_schedule() but only > on locations where it is safe to get freezed. Anyway, we need to > be careful here. s/freezed/frozen/ Bah, you made me look at the freezer code, karma reduction for you. And this is the arch typical freeze point if ever there was one, you're checking kthread_stop, if we can terminate the kthread, we can certainly get frozen. > BTW: What is the preferred way of freezing, please? Is it better > to end up in the fridge or is it fine to call freezer_do_not_count(); > or set PF_NOFREEZE when it is safe? freezable_schedule() is fine in this case. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 09/18] kthread: Make it easier to correctly sleep in iterant kthreads
On Fri 2015-06-05 18:10:21, Peter Zijlstra wrote:
> On Fri, Jun 05, 2015 at 05:01:08PM +0200, Petr Mladek wrote:
> > Many kthreads go into an interruptible sleep when there is nothing
> > to do. They should check if anyone did not requested the kthread
> > to terminate, freeze, or park in the meantime. It is easy to do
> > it a wrong way.
>
> INTERRUPTIBLE is the wrong state to idle in for kthreads, use
> TASK_IDLE.
>
> ---
>
> commit 80ed87c8a9ca0cad7ca66cf3bbdfb17559a66dcf
> Author: Peter Zijlstra
> Date: Fri May 8 14:23:45 2015 +0200
>
> sched/wait: Introduce TASK_NOLOAD and TASK_IDLE
>
> Currently people use TASK_INTERRUPTIBLE to idle kthreads and wait for
> 'work' because TASK_UNINTERRUPTIBLE contributes to the loadavg. Having
> all idle kthreads contribute to the loadavg is somewhat silly.
>
> Now mostly this works OK, because kthreads have all their signals
> masked. However there's a few sites where this is causing problems and
> TASK_UNINTERRUPTIBLE should be used, except for that loadavg issue.
>
> This patch adds TASK_NOLOAD which, when combined with
> TASK_UNINTERRUPTIBLE avoids the loadavg accounting.
>
> As most of imagined usage sites are loops where a thread wants to
> idle, waiting for work, a helper TASK_IDLE is introduced.
Just to be sure. Do you suggest to use TASK_IDLE everywhere in
kthreads or only when the uninterruptible sleep is really needed?
IMHO, we should not use TASK_IDLE in freezable kthreads because
it would break freezing. Well, we could freezable_schedule() but only
on locations where it is safe to get freezed. Anyway, we need to
be careful here.
BTW: What is the preferred way of freezing, please? Is it better
to end up in the fridge or is it fine to call freezer_do_not_count();
or set PF_NOFREEZE when it is safe?
The fridge looks more clean to me but in this case we should avoid
uninterruptible sleep as much as possible.
Best Regards,
Petr
> Signed-off-by: Peter Zijlstra (Intel)
> Cc: Julian Anastasov
> Cc: Linus Torvalds
> Cc: NeilBrown
> Cc: Oleg Nesterov
> Cc: Peter Zijlstra
> Cc: Thomas Gleixner
> Signed-off-by: Ingo Molnar
>
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index dd07ac03f82a..7de815c6fa78 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -218,9 +218,10 @@ print_cfs_rq(struct seq_file *m, int cpu, struct cfs_rq
> *cfs_rq);
> #define TASK_WAKEKILL128
> #define TASK_WAKING 256
> #define TASK_PARKED 512
> -#define TASK_STATE_MAX 1024
> +#define TASK_NOLOAD 1024
> +#define TASK_STATE_MAX 2048
>
> -#define TASK_STATE_TO_CHAR_STR "RSDTtXZxKWP"
> +#define TASK_STATE_TO_CHAR_STR "RSDTtXZxKWPN"
>
> extern char ___assert_task_state[1 - 2*!!(
> sizeof(TASK_STATE_TO_CHAR_STR)-1 != ilog2(TASK_STATE_MAX)+1)];
> @@ -230,6 +231,8 @@ extern char ___assert_task_state[1 - 2*!!(
> #define TASK_STOPPED (TASK_WAKEKILL | __TASK_STOPPED)
> #define TASK_TRACED (TASK_WAKEKILL | __TASK_TRACED)
>
> +#define TASK_IDLE(TASK_UNINTERRUPTIBLE | TASK_NOLOAD)
> +
> /* Convenience macros for the sake of wake_up */
> #define TASK_NORMAL (TASK_INTERRUPTIBLE | TASK_UNINTERRUPTIBLE)
> #define TASK_ALL (TASK_NORMAL | __TASK_STOPPED | __TASK_TRACED)
> @@ -245,7 +248,8 @@ extern char ___assert_task_state[1 - 2*!!(
> ((task->state & (__TASK_STOPPED | __TASK_TRACED)) != 0)
> #define task_contributes_to_load(task) \
> ((task->state & TASK_UNINTERRUPTIBLE) != 0 && \
> - (task->flags & PF_FROZEN) == 0)
> + (task->flags & PF_FROZEN) == 0 && \
> + (task->state & TASK_NOLOAD) == 0)
>
> #ifdef CONFIG_DEBUG_ATOMIC_SLEEP
>
> diff --git a/include/trace/events/sched.h b/include/trace/events/sched.h
> index 30fedaf3e56a..d57a575fe31f 100644
> --- a/include/trace/events/sched.h
> +++ b/include/trace/events/sched.h
> @@ -147,7 +147,8 @@ TRACE_EVENT(sched_switch,
> __print_flags(__entry->prev_state & (TASK_STATE_MAX-1), "|",
> { 1, "S"} , { 2, "D" }, { 4, "T" }, { 8, "t" },
> { 16, "Z" }, { 32, "X" }, { 64, "x" },
> - { 128, "K" }, { 256, "W" }, { 512, "P" }) : "R",
> + { 128, "K" }, { 256, "W" }, { 512, "P" },
> + { 1024, "N" }) : "R",
> __entry->prev_state & TASK_STATE_MAX ? "+" : "",
> __entry->next_comm, __entry->next_pid, __entry->next_prio)
> );
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
Re: [RFC PATCH 09/18] kthread: Make it easier to correctly sleep in iterant kthreads
On Fri, 5 Jun 2015 18:10:21 +0200 Peter Zijlstra pet...@infradead.org wrote: On Fri, Jun 05, 2015 at 05:01:08PM +0200, Petr Mladek wrote: Many kthreads go into an interruptible sleep when there is nothing to do. They should check if anyone did not requested the kthread to terminate, freeze, or park in the meantime. It is easy to do it a wrong way. INTERRUPTIBLE is the wrong state to idle in for kthreads, use TASK_IDLE. --- commit 80ed87c8a9ca0cad7ca66cf3bbdfb17559a66dcf Author: Peter Zijlstra pet...@infradead.org Date: Fri May 8 14:23:45 2015 +0200 sched/wait: Introduce TASK_NOLOAD and TASK_IDLE Currently people use TASK_INTERRUPTIBLE to idle kthreads and wait for 'work' because TASK_UNINTERRUPTIBLE contributes to the loadavg. Having all idle kthreads contribute to the loadavg is somewhat silly. Not to mention, tasks in TASK_UNINTERRUPTIBLE state for too long will trigger hung task detection. Now mostly this works OK, because kthreads have all their signals masked. However there's a few sites where this is causing problems and TASK_UNINTERRUPTIBLE should be used, except for that loadavg issue. This patch adds TASK_NOLOAD which, when combined with TASK_UNINTERRUPTIBLE avoids the loadavg accounting. As most of imagined usage sites are loops where a thread wants to idle, waiting for work, a helper TASK_IDLE is introduced. Signed-off-by: Peter Zijlstra (Intel) pet...@infradead.org Acked-by: Steven Rostedt rost...@goodmis.org -- Steve Cc: Julian Anastasov j...@ssi.bg Cc: Linus Torvalds torva...@linux-foundation.org Cc: NeilBrown ne...@suse.de Cc: Oleg Nesterov o...@redhat.com Cc: Peter Zijlstra pet...@infradead.org Cc: Thomas Gleixner t...@linutronix.de Signed-off-by: Ingo Molnar mi...@kernel.org diff --git a/include/linux/sched.h b/include/linux/sched.h -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 09/18] kthread: Make it easier to correctly sleep in iterant kthreads
On Fri 2015-06-05 18:10:21, Peter Zijlstra wrote:
On Fri, Jun 05, 2015 at 05:01:08PM +0200, Petr Mladek wrote:
Many kthreads go into an interruptible sleep when there is nothing
to do. They should check if anyone did not requested the kthread
to terminate, freeze, or park in the meantime. It is easy to do
it a wrong way.
INTERRUPTIBLE is the wrong state to idle in for kthreads, use
TASK_IDLE.
---
commit 80ed87c8a9ca0cad7ca66cf3bbdfb17559a66dcf
Author: Peter Zijlstra pet...@infradead.org
Date: Fri May 8 14:23:45 2015 +0200
sched/wait: Introduce TASK_NOLOAD and TASK_IDLE
Currently people use TASK_INTERRUPTIBLE to idle kthreads and wait for
'work' because TASK_UNINTERRUPTIBLE contributes to the loadavg. Having
all idle kthreads contribute to the loadavg is somewhat silly.
Now mostly this works OK, because kthreads have all their signals
masked. However there's a few sites where this is causing problems and
TASK_UNINTERRUPTIBLE should be used, except for that loadavg issue.
This patch adds TASK_NOLOAD which, when combined with
TASK_UNINTERRUPTIBLE avoids the loadavg accounting.
As most of imagined usage sites are loops where a thread wants to
idle, waiting for work, a helper TASK_IDLE is introduced.
Just to be sure. Do you suggest to use TASK_IDLE everywhere in
kthreads or only when the uninterruptible sleep is really needed?
IMHO, we should not use TASK_IDLE in freezable kthreads because
it would break freezing. Well, we could freezable_schedule() but only
on locations where it is safe to get freezed. Anyway, we need to
be careful here.
BTW: What is the preferred way of freezing, please? Is it better
to end up in the fridge or is it fine to call freezer_do_not_count();
or set PF_NOFREEZE when it is safe?
The fridge looks more clean to me but in this case we should avoid
uninterruptible sleep as much as possible.
Best Regards,
Petr
Signed-off-by: Peter Zijlstra (Intel) pet...@infradead.org
Cc: Julian Anastasov j...@ssi.bg
Cc: Linus Torvalds torva...@linux-foundation.org
Cc: NeilBrown ne...@suse.de
Cc: Oleg Nesterov o...@redhat.com
Cc: Peter Zijlstra pet...@infradead.org
Cc: Thomas Gleixner t...@linutronix.de
Signed-off-by: Ingo Molnar mi...@kernel.org
diff --git a/include/linux/sched.h b/include/linux/sched.h
index dd07ac03f82a..7de815c6fa78 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -218,9 +218,10 @@ print_cfs_rq(struct seq_file *m, int cpu, struct cfs_rq
*cfs_rq);
#define TASK_WAKEKILL128
#define TASK_WAKING 256
#define TASK_PARKED 512
-#define TASK_STATE_MAX 1024
+#define TASK_NOLOAD 1024
+#define TASK_STATE_MAX 2048
-#define TASK_STATE_TO_CHAR_STR RSDTtXZxKWP
+#define TASK_STATE_TO_CHAR_STR RSDTtXZxKWPN
extern char ___assert_task_state[1 - 2*!!(
sizeof(TASK_STATE_TO_CHAR_STR)-1 != ilog2(TASK_STATE_MAX)+1)];
@@ -230,6 +231,8 @@ extern char ___assert_task_state[1 - 2*!!(
#define TASK_STOPPED (TASK_WAKEKILL | __TASK_STOPPED)
#define TASK_TRACED (TASK_WAKEKILL | __TASK_TRACED)
+#define TASK_IDLE(TASK_UNINTERRUPTIBLE | TASK_NOLOAD)
+
/* Convenience macros for the sake of wake_up */
#define TASK_NORMAL (TASK_INTERRUPTIBLE | TASK_UNINTERRUPTIBLE)
#define TASK_ALL (TASK_NORMAL | __TASK_STOPPED | __TASK_TRACED)
@@ -245,7 +248,8 @@ extern char ___assert_task_state[1 - 2*!!(
((task-state (__TASK_STOPPED | __TASK_TRACED)) != 0)
#define task_contributes_to_load(task) \
((task-state TASK_UNINTERRUPTIBLE) != 0 \
- (task-flags PF_FROZEN) == 0)
+ (task-flags PF_FROZEN) == 0 \
+ (task-state TASK_NOLOAD) == 0)
#ifdef CONFIG_DEBUG_ATOMIC_SLEEP
diff --git a/include/trace/events/sched.h b/include/trace/events/sched.h
index 30fedaf3e56a..d57a575fe31f 100644
--- a/include/trace/events/sched.h
+++ b/include/trace/events/sched.h
@@ -147,7 +147,8 @@ TRACE_EVENT(sched_switch,
__print_flags(__entry-prev_state (TASK_STATE_MAX-1), |,
{ 1, S} , { 2, D }, { 4, T }, { 8, t },
{ 16, Z }, { 32, X }, { 64, x },
- { 128, K }, { 256, W }, { 512, P }) : R,
+ { 128, K }, { 256, W }, { 512, P },
+ { 1024, N }) : R,
__entry-prev_state TASK_STATE_MAX ? + : ,
__entry-next_comm, __entry-next_pid, __entry-next_prio)
);
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
Re: [RFC PATCH 09/18] kthread: Make it easier to correctly sleep in iterant kthreads
On Mon, 2015-06-08 at 12:01 +0200, Petr Mladek wrote: Just to be sure. Do you suggest to use TASK_IDLE everywhere in kthreads or only when the uninterruptible sleep is really needed? Always, only use INTERRUPTIBLE when you're actually interruptible, that is you want signals or such muck to terminate your wait. IMHO, we should not use TASK_IDLE in freezable kthreads because it would break freezing. How so? The task is IDLE, its not doing anything. Well, we could freezable_schedule() but only on locations where it is safe to get freezed. Anyway, we need to be careful here. s/freezed/frozen/ Bah, you made me look at the freezer code, karma reduction for you. And this is the arch typical freeze point if ever there was one, you're checking kthread_stop, if we can terminate the kthread, we can certainly get frozen. BTW: What is the preferred way of freezing, please? Is it better to end up in the fridge or is it fine to call freezer_do_not_count(); or set PF_NOFREEZE when it is safe? freezable_schedule() is fine in this case. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 09/18] kthread: Make it easier to correctly sleep in iterant kthreads
On Fri, Jun 05, 2015 at 05:01:08PM +0200, Petr Mladek wrote:
> Many kthreads go into an interruptible sleep when there is nothing
> to do. They should check if anyone did not requested the kthread
> to terminate, freeze, or park in the meantime. It is easy to do
> it a wrong way.
INTERRUPTIBLE is the wrong state to idle in for kthreads, use
TASK_IDLE.
---
commit 80ed87c8a9ca0cad7ca66cf3bbdfb17559a66dcf
Author: Peter Zijlstra
Date: Fri May 8 14:23:45 2015 +0200
sched/wait: Introduce TASK_NOLOAD and TASK_IDLE
Currently people use TASK_INTERRUPTIBLE to idle kthreads and wait for
'work' because TASK_UNINTERRUPTIBLE contributes to the loadavg. Having
all idle kthreads contribute to the loadavg is somewhat silly.
Now mostly this works OK, because kthreads have all their signals
masked. However there's a few sites where this is causing problems and
TASK_UNINTERRUPTIBLE should be used, except for that loadavg issue.
This patch adds TASK_NOLOAD which, when combined with
TASK_UNINTERRUPTIBLE avoids the loadavg accounting.
As most of imagined usage sites are loops where a thread wants to
idle, waiting for work, a helper TASK_IDLE is introduced.
Signed-off-by: Peter Zijlstra (Intel)
Cc: Julian Anastasov
Cc: Linus Torvalds
Cc: NeilBrown
Cc: Oleg Nesterov
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Signed-off-by: Ingo Molnar
diff --git a/include/linux/sched.h b/include/linux/sched.h
index dd07ac03f82a..7de815c6fa78 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -218,9 +218,10 @@ print_cfs_rq(struct seq_file *m, int cpu, struct cfs_rq
*cfs_rq);
#define TASK_WAKEKILL 128
#define TASK_WAKING256
#define TASK_PARKED512
-#define TASK_STATE_MAX 1024
+#define TASK_NOLOAD1024
+#define TASK_STATE_MAX 2048
-#define TASK_STATE_TO_CHAR_STR "RSDTtXZxKWP"
+#define TASK_STATE_TO_CHAR_STR "RSDTtXZxKWPN"
extern char ___assert_task_state[1 - 2*!!(
sizeof(TASK_STATE_TO_CHAR_STR)-1 != ilog2(TASK_STATE_MAX)+1)];
@@ -230,6 +231,8 @@ extern char ___assert_task_state[1 - 2*!!(
#define TASK_STOPPED (TASK_WAKEKILL | __TASK_STOPPED)
#define TASK_TRACED(TASK_WAKEKILL | __TASK_TRACED)
+#define TASK_IDLE (TASK_UNINTERRUPTIBLE | TASK_NOLOAD)
+
/* Convenience macros for the sake of wake_up */
#define TASK_NORMAL(TASK_INTERRUPTIBLE | TASK_UNINTERRUPTIBLE)
#define TASK_ALL (TASK_NORMAL | __TASK_STOPPED | __TASK_TRACED)
@@ -245,7 +248,8 @@ extern char ___assert_task_state[1 - 2*!!(
((task->state & (__TASK_STOPPED | __TASK_TRACED)) != 0)
#define task_contributes_to_load(task) \
((task->state & TASK_UNINTERRUPTIBLE) != 0 && \
-(task->flags & PF_FROZEN) == 0)
+(task->flags & PF_FROZEN) == 0 && \
+(task->state & TASK_NOLOAD) == 0)
#ifdef CONFIG_DEBUG_ATOMIC_SLEEP
diff --git a/include/trace/events/sched.h b/include/trace/events/sched.h
index 30fedaf3e56a..d57a575fe31f 100644
--- a/include/trace/events/sched.h
+++ b/include/trace/events/sched.h
@@ -147,7 +147,8 @@ TRACE_EVENT(sched_switch,
__print_flags(__entry->prev_state & (TASK_STATE_MAX-1), "|",
{ 1, "S"} , { 2, "D" }, { 4, "T" }, { 8, "t" },
{ 16, "Z" }, { 32, "X" }, { 64, "x" },
- { 128, "K" }, { 256, "W" }, { 512, "P" }) : "R",
+ { 128, "K" }, { 256, "W" }, { 512, "P" },
+ { 1024, "N" }) : "R",
__entry->prev_state & TASK_STATE_MAX ? "+" : "",
__entry->next_comm, __entry->next_pid, __entry->next_prio)
);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 09/18] kthread: Make it easier to correctly sleep in iterant kthreads
On Fri, Jun 05, 2015 at 05:01:08PM +0200, Petr Mladek wrote:
Many kthreads go into an interruptible sleep when there is nothing
to do. They should check if anyone did not requested the kthread
to terminate, freeze, or park in the meantime. It is easy to do
it a wrong way.
INTERRUPTIBLE is the wrong state to idle in for kthreads, use
TASK_IDLE.
---
commit 80ed87c8a9ca0cad7ca66cf3bbdfb17559a66dcf
Author: Peter Zijlstra pet...@infradead.org
Date: Fri May 8 14:23:45 2015 +0200
sched/wait: Introduce TASK_NOLOAD and TASK_IDLE
Currently people use TASK_INTERRUPTIBLE to idle kthreads and wait for
'work' because TASK_UNINTERRUPTIBLE contributes to the loadavg. Having
all idle kthreads contribute to the loadavg is somewhat silly.
Now mostly this works OK, because kthreads have all their signals
masked. However there's a few sites where this is causing problems and
TASK_UNINTERRUPTIBLE should be used, except for that loadavg issue.
This patch adds TASK_NOLOAD which, when combined with
TASK_UNINTERRUPTIBLE avoids the loadavg accounting.
As most of imagined usage sites are loops where a thread wants to
idle, waiting for work, a helper TASK_IDLE is introduced.
Signed-off-by: Peter Zijlstra (Intel) pet...@infradead.org
Cc: Julian Anastasov j...@ssi.bg
Cc: Linus Torvalds torva...@linux-foundation.org
Cc: NeilBrown ne...@suse.de
Cc: Oleg Nesterov o...@redhat.com
Cc: Peter Zijlstra pet...@infradead.org
Cc: Thomas Gleixner t...@linutronix.de
Signed-off-by: Ingo Molnar mi...@kernel.org
diff --git a/include/linux/sched.h b/include/linux/sched.h
index dd07ac03f82a..7de815c6fa78 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -218,9 +218,10 @@ print_cfs_rq(struct seq_file *m, int cpu, struct cfs_rq
*cfs_rq);
#define TASK_WAKEKILL 128
#define TASK_WAKING256
#define TASK_PARKED512
-#define TASK_STATE_MAX 1024
+#define TASK_NOLOAD1024
+#define TASK_STATE_MAX 2048
-#define TASK_STATE_TO_CHAR_STR RSDTtXZxKWP
+#define TASK_STATE_TO_CHAR_STR RSDTtXZxKWPN
extern char ___assert_task_state[1 - 2*!!(
sizeof(TASK_STATE_TO_CHAR_STR)-1 != ilog2(TASK_STATE_MAX)+1)];
@@ -230,6 +231,8 @@ extern char ___assert_task_state[1 - 2*!!(
#define TASK_STOPPED (TASK_WAKEKILL | __TASK_STOPPED)
#define TASK_TRACED(TASK_WAKEKILL | __TASK_TRACED)
+#define TASK_IDLE (TASK_UNINTERRUPTIBLE | TASK_NOLOAD)
+
/* Convenience macros for the sake of wake_up */
#define TASK_NORMAL(TASK_INTERRUPTIBLE | TASK_UNINTERRUPTIBLE)
#define TASK_ALL (TASK_NORMAL | __TASK_STOPPED | __TASK_TRACED)
@@ -245,7 +248,8 @@ extern char ___assert_task_state[1 - 2*!!(
((task-state (__TASK_STOPPED | __TASK_TRACED)) != 0)
#define task_contributes_to_load(task) \
((task-state TASK_UNINTERRUPTIBLE) != 0 \
-(task-flags PF_FROZEN) == 0)
+(task-flags PF_FROZEN) == 0 \
+(task-state TASK_NOLOAD) == 0)
#ifdef CONFIG_DEBUG_ATOMIC_SLEEP
diff --git a/include/trace/events/sched.h b/include/trace/events/sched.h
index 30fedaf3e56a..d57a575fe31f 100644
--- a/include/trace/events/sched.h
+++ b/include/trace/events/sched.h
@@ -147,7 +147,8 @@ TRACE_EVENT(sched_switch,
__print_flags(__entry-prev_state (TASK_STATE_MAX-1), |,
{ 1, S} , { 2, D }, { 4, T }, { 8, t },
{ 16, Z }, { 32, X }, { 64, x },
- { 128, K }, { 256, W }, { 512, P }) : R,
+ { 128, K }, { 256, W }, { 512, P },
+ { 1024, N }) : R,
__entry-prev_state TASK_STATE_MAX ? + : ,
__entry-next_comm, __entry-next_pid, __entry-next_prio)
);
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
