linux-kernel - Re: [PATCH 7/8] ACPI: acpi_idle: touch TS

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]

Date:	Fri, 28 May 2010 13:59:18 -0400 (EDT)
From:	Len Brown <lenb@...nel.org>
To:	Venkatesh Pallipadi <venki@...gle.com>
Cc:	linux-pm@...ts.linux-foundation.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 7/8] ACPI: acpi_idle: touch TS_POLLING only in the
 non-MWAIT case

On Fri, 28 May 2010, Venkatesh Pallipadi wrote:

> On Thu, May 27, 2010 at 11:02 PM, Len Brown <lenb@...nel.org> wrote:
> > From: Len Brown <len.brown@...el.com>
> >
> > commit d306ebc28649b89877a22158fe0076f06cc46f60
> > (ACPI: Be in TS_POLLING state during mwait based C-state entry)
> > fixed an important power & performance issue where ACPI c2 and c3 C-states
> > were clearing TS_POLLING even when using MWAIT (ACPI_STATE_FFH).
> > That bug had been causing us to receive redundant scheduling interrups
> > when we had already been woken up by MONITOR/MWAIT.
> >
> > Following up on that...
> >
> > In the MWAIT case, we don't have to subsequently
> > check need_resched(), as that c heck was there
> > for the TS_POLLING-clearing case.
> >
> > Note that not only does the cpuidle calling function
> > already check need_resched() before calling us, the
> > low-level entry into monitor/mwait calls it twice --
> > guaranteeing that a write to the trigger address
> > can not go un-noticed.
> 
> Ack this part of the change.
> 
> > Also, in this case, we don't have to set TS_POLLING
> > when we wake, because we never cleared it.
> 
> I thought about this part of the change while working on the original
> patch. But decided to leave the set to be done unconditionally as in
> this case we are replacing "one write" by either "one read and one
> jump" or "one read and one write" and I am not sure we gain much by
> that.

I don't know if the write is more expensive than the read and branch.
In the scheme of things, these things are free and it is the IO
accesses and locks in the idle path that take time.

But when I saw this code fragment incorrectly copied into
the new sfi_idle driver, I decided it was time to change it
to make logical sense to the reader.

thanks,
-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/