Standardize the idle polling indicator to TIF_POLLING_NRFLAG such that
both TIF_NEED_RESCHED and TIF_POLLING_NRFLAG are in the same word.
This will allow us, using fetch_or(), to both set NEED_RESCHED and
check for POLLING_NRFLAG in a single operation and avoid pointless
wakeups.
Changing from the non-atomic thread_info::status flags to the atomic
thread_info::flags shouldn't be a big issue since most polling state
changes were followed/preceded by a full memory barrier anyway.
Cc: Thomas Gleixner <t...@linutronix.de>
Cc: Andy Lutomirski <l...@amacapital.net>
Cc: Tony Luck <tony.l...@intel.com>
Signed-off-by: Peter Zijlstra <pet...@infradead.org>
---
arch/ia64/include/asm/thread_info.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--- a/arch/ia64/include/asm/thread_info.h
+++ b/arch/ia64/include/asm/thread_info.h
@@ -107,6 +107,7 @@ struct thread_info {
#define TIF_MCA_INIT 18 /* this task is processing MCA or INIT
*/
#define TIF_DB_DISABLED 19 /* debug trap disabled for
fsyscall */
#define TIF_RESTORE_RSE 21 /* user RBS is newer than
kernel RBS */
+#define TIF_POLLING_NRFLAG 22 /* idle is polling for TIF_NEED_RESCHED
*/
#define _TIF_SYSCALL_TRACE (1 << TIF_SYSCALL_TRACE)
#define _TIF_SYSCALL_AUDIT (1 << TIF_SYSCALL_AUDIT)
@@ -118,6 +119,7 @@ struct thread_info {
#define _TIF_MCA_INIT (1 << TIF_MCA_INIT)
#define _TIF_DB_DISABLED (1 << TIF_DB_DISABLED)
#define _TIF_RESTORE_RSE (1 << TIF_RESTORE_RSE)
+#define _TIF_POLLING_NRFLAG (1 << TIF_POLLING_NRFLAG)
/* "work to do on user-return" bits */
#define TIF_ALLWORK_MASK
(_TIF_SIGPENDING|_TIF_NOTIFY_RESUME|_TIF_SYSCALL_AUDIT|\
@@ -125,7 +127,6 @@ struct thread_info {
/* like TIF_ALLWORK_BITS but sans TIF_SYSCALL_TRACE or TIF_SYSCALL_AUDIT */
#define TIF_WORK_MASK
(TIF_ALLWORK_MASK&~(_TIF_SYSCALL_TRACE|_TIF_SYSCALL_AUDIT))
-#define TS_POLLING 1 /* true if in idle loop and not
sleeping */
#define TS_RESTORE_SIGMASK 2 /* restore signal mask in do_signal() */
#ifndef __ASSEMBLY__
--
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/
