The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Lee Revell <rlrevell@joe-job.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@osdl.org>
Subject: Re: preempt timing violations
Date: Mon, 26 Jul 2004 05:09:14 -0400	[thread overview]
Message-ID: <1090832953.6936.114.camel@mindpipe> (raw)
In-Reply-To: <20040726085002.GA25519@elte.hu>

On Mon, 2004-07-26 at 04:50, Ingo Molnar wrote:
> * Lee Revell <rlrevell@joe-job.com> wrote:
> 
> > Latency with 2.6.8-rc2 + voluntary-preempt-I4 is the best so far. 
> > After extended testing there only seem to be a few hot spots.  In
> > several minutes I saw an 11ms violation, a 14ms violation, and several
> > 2ms violations.
> > 
> > get_user_pages() is much better in 2.6.8-rc1-mm1 than 2.6.8-rc2.  Is
> > there any chance of getting the fix into mainline?
> 
> in -J3 i've added a cond_resched to the latency-generating point of
> get_user_pages(). (The biggest latencies happen via
> make_pages_present(), which gets triggered by mlockall()/MAP_LOCKED.)
> 

OK, great, this is the biggest remaing issue with -I4, because jackd
does that a lot.

> > 2ms non-preemptible critical section violated 1 ms preempt threshold
> > starting at unmap_vmas+0x1ff/0x210 and ending at
> > unmap_vmas+0x1f5/0x210
> 
> this is the normal sys_exit()->exit_mmap()->unmap_vmas() path. It's
> weird that it generated a 2ms latency. What are the values of
> voluntary_preemption and kernel_preemption on your current kernel? With
> a 2:0 setting we ought to have a reschedule point every 32 pages.  Do
> you know which application triggers this latency and is it easy to
> reproduce?
> 

2 and 1.  Now that I think about it, this could have happened during
bootup, before my rc.local set these.  I will try passing them on the
kernel command line. 

Not sure I understand the difference between 2:1 and 2:0.   Would the
latter make the kernel only preemptible at the voluntary preemption
points?

> > 14ms non-preemptible critical section violated 1 ms preempt threshold 
> > starting at tty_write+0x1b6/0x290 and ending at schedule+0x2fd/0x5b0
> 
> does this one trigger when you are using the VGA console? (or fbcon)?
> 
> it's not immediately obvious to me precisely where this latency comes
> from, it would be nice to know how to reproduce it.

It think this one was caused by switching virtual consoles.  At one
point Andrew Morton suggested I remove the (un)lock_kernel calls from
do_tty_write.  This fixed the problem, with no detectable side effects. 
Maybe this could be incorporated into voluntary-preempt, it would be
useful to have more than one person to test it.

Lee


  reply	other threads:[~2004-07-26  9:09 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-07-26  3:51 preempt timing violations Lee Revell
2004-07-26  8:50 ` Ingo Molnar
2004-07-26  9:09   ` Lee Revell [this message]
2004-07-26  9:22     ` Ingo Molnar
2004-07-26  9:25     ` Ingo Molnar
2004-07-26 15:43   ` preempt timing violations (unmap_vmas) Rudo Thomas

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=1090832953.6936.114.camel@mindpipe \
    --to=rlrevell@joe-job.com \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    /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