From: Heikki Lindholm <holindho@domain.hid>
To: adeos-main@gna.org
Cc: rtai-dev@domain.hid, Philippe Gerum <rpm@xenomai.org>
Subject: [Adeos-main] PATCH: adeos handle_event losing events
Date: Wed, 31 Aug 2005 14:54:36 +0300 [thread overview]
Message-ID: <43159A7C.9020008@domain.hid> (raw)
[-- Attachment #1: Type: text/plain, Size: 989 bytes --]
Hello,
While processing __adeos_handle_event enables interrupts for the ectual
event handler periods. Interrupts might happen then and only logged for
domains lower than the current domain in the __adeos_handle_event loop.
The logged irqs would normally get replayed at the next real interrupt
if the domain that caused the event was lower than the ones the
interrupts were logged in or if it wasn't lower, at the next
suspend_domain. On powersave-enabled ppc machines this might cause a
chain where the cpu goes napping and wakes at the next timer tick which,
having possibly been missed at *handle_event, happens after maximum
decrementer period (~minutes).
The following patch seems to help in the described case, but I've also
observed another case where interrupt seems to get dropped altogether.
Performance didn't seem to suffer much from the patch. If anything, the
latency/cruncher results got better. This is for the non-threaded
domains case.
-- Heikki Lindholm
[-- Attachment #2: adeos-handle_event-p1.patch --]
[-- Type: text/plain, Size: 1032 bytes --]
--- kernel/adeos.c.orig 2005-08-31 12:01:30.002707784 +0300
+++ kernel/adeos.c 2005-08-31 13:10:25.148070136 +0300
@@ -196,6 +196,7 @@
adeos_declare_cpuid;
adevinfo_t evinfo;
int propagate = 1;
+ int notfirst = 0;
adeos_lock_cpu(flags);
@@ -204,7 +205,20 @@
list_for_each_safe(pos,npos,&__adeos_pipeline) {
next_domain = list_entry(pos,adomain_t,p_link);
-
+ /* did the previous unlock_cpu gap cause interrupts here? */
+ if (notfirst && next_domain != adp_root && !test_bit(IPIPE_STALL_FLAG,
+ &next_domain->cpudata[cpuid].status) &&
+ next_domain->cpudata[cpuid].irq_pending_hi != 0)
+ {
+ adp_cpu_current[cpuid] = next_domain;
+ __adeos_sync_stage(IPIPE_IRQMASK_ANY);
+
+ if (adp_cpu_current[cpuid] != next_domain)
+ /* Something has changed the current domain under our
+ * feet recycling the register set; take note. */
+ this_domain = adp_cpu_current[cpuid];
+ }
+
if (next_domain->events[event].handler != NULL)
{
adp_cpu_current[cpuid] = next_domain;
next reply other threads:[~2005-08-31 11:54 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-08-31 11:54 Heikki Lindholm [this message]
2005-08-31 12:35 ` [Adeos-main] PATCH: adeos handle_event losing events Philippe Gerum
2005-08-31 13:09 ` Philippe Gerum
2005-08-31 13:46 ` [Adeos-main] PATCH: adeos handle_event losing events *corrected* Heikki Lindholm
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=43159A7C.9020008@domain.hid \
--to=holindho@domain.hid \
--cc=adeos-main@gna.org \
--cc=rpm@xenomai.org \
--cc=rtai-dev@domain.hid \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.