On 10/11/2011 03:10 PM, Paul Davis wrote:
On Tue, Oct 11, 2011 at 5:33 PM, Michael Ostm...@museresearch.com wrote:
We have gotten some interesting results from cyclictest and the new ftrace
system. Hopefully that will point us to some kernel latency that we can work
around or fix.
it would
On Mon, Oct 24, 2011 at 8:28 PM, Michael Ost m...@museresearch.com wrote:
As promised, here's what I found.
thanks a lot for filling us in. Some of that is not so relevant to
non-wine-hosted contexts, but its useful info either way.
--p
___
On 10/07/2011 08:07 PM, Robin Gareus wrote:
It's a bit dated but so is your 2.6.24.3 kernel. You will need to
compile the kernel with CONFIG_PREEMPT_TRACER=y CONFIG_SCHED_TRACER=y
under Kernel hacking - Tracers - .. to get access to
/sys/kernel/debug/tracing/
I've got some output, but am
On 10/13/2011 01:28 AM, Michael Ost wrote:
On 10/07/2011 08:07 PM, Robin Gareus wrote:
It's a bit dated but so is your 2.6.24.3 kernel. You will need to
compile the kernel with CONFIG_PREEMPT_TRACER=y CONFIG_SCHED_TRACER=y
under Kernel hacking - Tracers - .. to get access to
I wrote:
What is the time quantum that sched_rr_get_interval() returns for these
threads?
Bah, the documentation of sched_rr_get_interval() is wrong; the kernel
uses a fixed RR time quantum of 100 ms which cannot be changed (except
by changing DEF_TIMESLICE in kernel/sched.c).
This means that,
On 10/11/2011 01:52 AM, Clemens Ladisch wrote:
I wrote:
What is the time quantum that sched_rr_get_interval() returns for these
threads?
Bah, the documentation of sched_rr_get_interval() is wrong; the kernel
uses a fixed RR time quantum of 100 ms which cannot be changed (except
by changing
On Tue, Oct 11, 2011 at 5:33 PM, Michael Ost m...@museresearch.com wrote:
We have gotten some interesting results from cyclictest and the new ftrace
system. Hopefully that will point us to some kernel latency that we can work
around or fix.
it would be really great if you could share at least
On 10/11/2011 03:10 PM, Paul Davis wrote:
On Tue, Oct 11, 2011 at 5:33 PM, Michael Ostm...@museresearch.com wrote:
We have gotten some interesting results from cyclictest and the new ftrace
system. Hopefully that will point us to some kernel latency that we can work
around or fix.
it would
On 10/07/2011 08:07 PM, Robin Gareus wrote:
On 10/08/2011 03:25 AM, Michael Ost wrote:
Hi list,
We are seeing unexpected interruptions of SCHED_RR audio processing
threads, and are struggling to understand why they are happening. Does
anyone have any good tips or tools to suggest to help
On 10/10/2011 07:55 PM, Michael Ost wrote:
I'm not totally clear on how SCHED_RR and SCHED_FIFO relate though.
Would (a) a SCHED_RR/50 thread be run ahead of a SCHED_FIFO/49 thread?
yes.
The scheduling policy only determines the ordering within the list of
runnable processes with equal static
On 10/10/2011 09:05 PM, Robin Gareus wrote:
On 10/10/2011 07:55 PM, Michael Ost wrote:
I'm not totally clear on how SCHED_RR and SCHED_FIFO relate though.
Would (a) a SCHED_RR/50 thread be run ahead of a SCHED_FIFO/49 thread?
yes.
The scheduling policy only determines the ordering
On Mon, Oct 10, 2011 at 09:08:51PM +0200, Robin Gareus wrote:
And would (b) a SCHED_RR/50 thread interrupt a running SCHED_FIFO/49
thread?
yes.
OOPS. I misread the question. The answer is No.
The explanation is correct:
All scheduling is preemptive: if a process with a higher
On 10/10/2011 09:31 PM, Fons Adriaensen wrote:
On Mon, Oct 10, 2011 at 09:08:51PM +0200, Robin Gareus wrote:
And would (b) a SCHED_RR/50 thread interrupt a running SCHED_FIFO/49
thread?
yes.
OOPS. I misread the question. The answer is No.
The explanation is correct:
All scheduling is
On 10/07/2011 07:46 PM, Devin Anderson wrote:
On Fri, Oct 7, 2011 at 6:25 PM, Michael Ostm...@museresearch.com wrote:
We are seeing unexpected interruptions of SCHED_RR audio processing threads,
snip
bitching
snip
Wow, a painful response. It's taken me all weekend to figure out how to
On Mon, Oct 10, 2011 at 12:38 PM, Michael Ost m...@museresearch.com wrote:
On 10/07/2011 07:46 PM, Devin Anderson wrote:
On Fri, Oct 7, 2011 at 6:25 PM, Michael Ostm...@museresearch.com
wrote:
We are seeing unexpected interruptions of SCHED_RR audio processing
threads,
snip
bitching
Would (a) a SCHED_RR/50 thread be run ahead of a SCHED_FIFO/49 thread?
We have three answers, yes, no, and maybe. According to the kernel scheduler
the
answer is yes. The kernel does not actually have the final say here though
which is
why the answers no and maybe can be equally valid.
On 10/10/2011 01:37 PM, Nick Copeland wrote:
Would (a) a SCHED_RR/50 thread be run ahead of a SCHED_FIFO/49 thread?
We have three answers, yes, no, and maybe. According to the kernel
scheduler the
answer is yes. The kernel does not actually have the final say here
though which is
why the
Michael Ost wrote:
Have you ever seen migration or watchdog hold the CPU for any length of
time?
This shouldn't happen.
I was curious about migration since
/proc/sys/kernel/sched_migration_cost = 50
When migrating threads to another CPU (core), there is no big delay
because real-time
On 10/10/2011 03:04 PM, Clemens Ladisch wrote:
Michael Ost wrote:
Have you ever seen migration or watchdog hold the CPU for any length of
time?
This shouldn't happen.
I was curious about migration since
/proc/sys/kernel/sched_migration_cost = 50
When migrating threads to another CPU
Michael Ost wrote:
The higher priority threads in the system are:
...
* IRQ8 (rtc) - FIFO/99
Why does this interrupt get such a high priority?
(Not that it matters as I don't expect it to be used at all ...)
Are there issues with memory mapping, that can block other unrelated
threads?
Then
Hi list,
We are seeing unexpected interruptions of SCHED_RR audio processing
threads, and are struggling to understand why they are happening. Does
anyone have any good tips or tools to suggest to help figure out what is
preempting or delaying realtime audio threads?
The issues are coming
On Fri, Oct 7, 2011 at 6:25 PM, Michael Ost m...@museresearch.com wrote:
We are seeing unexpected interruptions of SCHED_RR audio processing threads,
and are struggling to understand why they are happening. Does anyone have
any good tips or tools to suggest to help figure out what is
On 10/08/2011 03:25 AM, Michael Ost wrote:
Hi list,
We are seeing unexpected interruptions of SCHED_RR audio processing
threads, and are struggling to understand why they are happening. Does
anyone have any good tips or tools to suggest to help figure out what is
preempting or delaying
23 matches
Mail list logo
