lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-id: <alpine.LFD.2.00.1005270138320.8496@localhost.localdomain>
Date:	Thu, 27 May 2010 01:47:29 -0400 (EDT)
From:	Len Brown <lenb@...nel.org>
To:	Milton Miller <miltonm@....com>
Cc:	Len Brown <len.brown@...el.com>,
	Peter Zijlstra <peterz@...radead.org>,
	linux-acpi@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: (No subject header)

On Thu, 27 May 2010, Milton Miller wrote:

> 
> [Hmm, why did this not appear in patchwork.kernel.org?  Now
> I have to guess a CC list.]
> 
> On Wed, 26 May 2010 around 22:43:50 -0400 (EDT), Len Brown wrote:
> > From: Len Brown <len.brown@...el.com>
> > 
> > TS_POLLING set tells the scheduler a task will poll
> > need_resched() to look for work.
> > 
> 
> True
> 
> > TS_POLLING clear tells resched_task() and wake_up_idle_cpu()
> > that the remote CPU is sleeping in idle, and thus requires
> > a reschedule interrupt to wake them to notice work.
> 
> No, that only applies to the idle task.
> 
> 
> > 
> > Update the description of TS_POLLING to reflect how it works.
> > "cleared when sleeping in idle, requiring reschedule interrupt"
> 
> That would imply its set for every normal task that is not in some
> kind of sleep state.

you're right, just the idle task sets this flag.

> > Signed-off-by: Len Brown <len.brown@...el.com>
> > Acked-by: Peter Zijlstra <peterz@...radead.org>
> 
> > -#define TS_POLLING		0x0004	/* true if in idle loop
> > -					   and not sleeping */
> > +#define TS_POLLING		0x0004	/* clear when sleeping in idle
> > +					   requiring reschedule interrupt */
> 
> How about "idle task polling need_resched, skip sending interrupt"?

I think that is an improvement over my wording.

Though technically we're not polling need_resched in the case
I have in mind.  The hardware is snooping any write to the thread flags
via MONITOR/MWAIT trigger address.

cheers,
-Len Brown, Intel Open Source Technology Center




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ