From: Dominik Brodowski <linux@dominikbrodowski.net>
To: Con Kolivas <kernel@kolivas.org>
Cc: linux kernel mailing list <linux-kernel@vger.kernel.org>,
ck list <ck@vds.kolivas.org>, Tony Lindgren <tony@atomide.com>,
Adam Belay <abelay@novell.com>,
Daniel Petrini <d.pensator@gmail.com>,
vatsa@in.ibm.com, acpi-devel@lists.sourceforge.net
Subject: busmaster and C-States [Was: [PATCH] i386 no idle HZ aka Dynticks 051203]
Date: Sun, 4 Dec 2005 13:55:12 +0100 [thread overview]
Message-ID: <20051204125512.GA9501@dominikbrodowski.de> (raw)
In-Reply-To: <200512041737.07996.kernel@kolivas.org>
Instead of Con Koliva's approach to fix dyntick and the busmaster logic in
the ACPI idle handler (see
http://ck.kolivas.org/patches/dyn-ticks/split-out/dyntick-busmaster_support.patch
) I propose this different patch as a replacement. Its
skipped_since_bm_check() is broken, as it returns the number of ticks we
hope to go to sleep for _now_, not how long we slept last time.
Some test result:
ck:
*C2: type[C2] promotion[C3] demotion[C1] latency[001]
usage[00066141] time[00000000001817309417]
C3: type[C3] promotion[--] demotion[C2] latency[085]
usage[00005760] time[00000000000138436523]
At average, sleeping for 7 ticks when in C2
At average, sleeping for 6 ticks when in C3
me:
C2: type[C2] promotion[C3] demotion[C1] latency[001]
usage[00143551] time[00000000002930357624]
*C3: type[C3] promotion[--] demotion[C2] latency[085]
usage[00079181] time[00000000002733459218]
At average, sleeping for 5 ticks when in C2
At average, sleeping for 9 ticks when in C3
Not perfect yet (but see the next patch), but better.
Only avoid entering C3-type sleep if there is bus master activity at the
moment.
Also, bus mastering activity going on while we slept can be ignored.
Therefore, adjust the bm_check_timestamp accordingly.
Signed-off-by: Dominik Brodowski <linux@dominikbrodowski.net>
Index: working-tree/drivers/acpi/processor_idle.c
===================================================================
--- working-tree.orig/drivers/acpi/processor_idle.c
+++ working-tree/drivers/acpi/processor_idle.c
@@ -256,7 +256,7 @@ static void acpi_processor_idle(void)
pr->power.bm_check_timestamp = jiffies;
/*
- * Apply bus mastering demotion policy. Automatically demote
+ * If bus mastering is active, automatically demote
* to avoid a faulty transition. Note that the processor
* won't enter a low-power state during this call (to this
* funciton) but should upon the next.
@@ -267,7 +267,7 @@ static void acpi_processor_idle(void)
* qualification. This may, however, introduce DMA
* issues (e.g. floppy DMA transfer overrun/underrun).
*/
- if (pr->power.bm_activity & cx->demotion.threshold.bm) {
+ if (bm_status && cx->demotion.threshold.bm) {
local_irq_enable();
next_state = cx->demotion.state;
goto end;
@@ -391,6 +391,10 @@ static void acpi_processor_idle(void)
cx->time += (PM_TIMER_FREQUENCY / (2 * HZ));
}
+ if (pr->flags.bm_check)
+ pr->power.bm_check_timestamp += sleep_ticks /
+ (PM_TIMER_FREQUENCY / HZ);
+
next_state = pr->power.state;
/*
next prev parent reply other threads:[~2005-12-04 13:01 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-04 6:37 [PATCH] i386 no idle HZ aka Dynticks 051203 Con Kolivas
2005-12-04 12:24 ` fix cpufreq-ondemand by accounting skipped ticks as idle ticks [Was: [PATCH] i386 no idle HZ aka Dynticks 051203] Dominik Brodowski
2005-12-04 12:32 ` Con Kolivas
2005-12-05 2:02 ` Con Kolivas
2005-12-04 12:32 ` Account time spent in C-States " Dominik Brodowski
2005-12-04 12:55 ` Dominik Brodowski [this message]
2005-12-04 13:01 ` C-State policy and dynticks " Dominik Brodowski
2005-12-04 14:33 ` Dyntick effectiveness " Dominik Brodowski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20051204125512.GA9501@dominikbrodowski.de \
--to=linux@dominikbrodowski.net \
--cc=abelay@novell.com \
--cc=acpi-devel@lists.sourceforge.net \
--cc=ck@vds.kolivas.org \
--cc=d.pensator@gmail.com \
--cc=kernel@kolivas.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tony@atomide.com \
--cc=vatsa@in.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®