public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@osdl.org>
To: Con Kolivas <kernel@kolivas.org>
Cc: devenyga@mcmaster.ca, ck@vds.kolivas.org,
	linux-kernel@vger.kernel.org, wli@holomorphy.com
Subject: Re: Preempt Threshold Measurements
Date: Mon, 12 Jul 2004 23:14:06 -0700	[thread overview]
Message-ID: <20040712231406.427caa2a.akpm@osdl.org> (raw)
In-Reply-To: <cone.1089697919.186986.12958.502@pc.kolivas.org>

Con Kolivas <kernel@kolivas.org> wrote:
>
> Andrew Morton writes:
> 
> > Con Kolivas <kernel@kolivas.org> wrote:
> >> Certainly the do_munmap and exit_mmap seem to be repeat offenders on my 
> >> machine too (more the latter in my case).
> >> 
> > 
> > This is a false positive.  Nothing is setting need_resched(), so
> > unmap_vmas() doesn't bother dropping the lock.
> 
> Ok well excluding do_munmap and exit_mmap the ones that have shown up 
> (some more frequently than others) are: 
> 
> 6ms at ksoftirqd+0x6b

Dunno.  There's an unresolved RCU dentry reaping problem, but that's
unlikely to occur within ksoftirqd context.

> 2ms at sys_ioctl+0x47

uses lock_kernel() at the top level.  Need to know the call trace to work
out who the offender is.  rtc-debug+amlat will tell you that, because it
catches the CPU hog while it's being hoggy, rather than after it has
finished.

> 2ms at b44_open

Lots of udelays() inside spin_lock_irq().  This is a "don't do that", I
suspect.

> 6ms at fget+0x28

Would need to see the amlat trace.

> 2ms at write_ordered_buffers+0x37

reiserfs

> 4ms at blkdev_put+0x48

This can run under one of two depths of lock_kernel.  filemap_fdatawrite()
and filemap_fdatawait() both do cond_resched(), so this is odd.

Try this:

--- 25/mm/truncate.c~truncate_inode_pages-latency-fix	2004-07-12 23:12:53.871816320 -0700
+++ 25-akpm/mm/truncate.c	2004-07-12 23:13:00.993733624 -0700
@@ -155,6 +155,7 @@ void truncate_inode_pages(struct address
 
 	next = start;
 	for ( ; ; ) {
+		cond_resched();
 		if (!pagevec_lookup(&pvec, mapping, next, PAGEVEC_SIZE)) {
 			if (next == start)
 				break;
_

> 5ms at add_wait_queue+0x21

Need to see the whole trace.

> Now which of the above are not false positives and should I try to extract 
> the exact locations of them?

You'll get better traces from

http://www.zip.com.au/~akpm/linux/patches/stuff/rtc-debug.patch
and
http://www.zip.com.au/~akpm/linux/amlat.tar.gz

Just apply rtc-debug, set CONFIG_RTC=y and run `amlat' as root while doing
testing.


  reply	other threads:[~2004-07-13  6:15 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-07-12 23:43 Preempt Threshold Measurements Gabriel Devenyi
2004-07-12 23:59 ` Con Kolivas
2004-07-13  0:15   ` Gabriel Devenyi
2004-07-13  2:40 ` William Lee Irwin III
2004-07-13  2:48   ` [ck] " Gabriel Devenyi
2004-07-13  2:54     ` Con Kolivas
2004-07-13  4:01       ` Andrew Morton
2004-07-13  5:51         ` Con Kolivas
2004-07-13  6:14           ` Andrew Morton [this message]
2004-07-13  8:03             ` Lee Revell
2004-07-13 10:26             ` Con Kolivas
2004-07-13 21:52             ` Con Kolivas
2004-07-13 10:08         ` William Lee Irwin III
2004-07-13 10:40           ` William Lee Irwin III
2004-07-13 11:07             ` Lenar Lõhmus
2004-07-13 11:13               ` William Lee Irwin III
2004-07-13  2:55     ` [ck] " William Lee Irwin III
2004-07-13  3:09       ` Gabriel Devenyi
2004-07-13  4:07       ` Andrew Morton
2004-07-13  5:34         ` Con Kolivas
2004-07-13  5:48           ` Nick Piggin
2004-07-13 10:14             ` William Lee Irwin III
2004-07-14 10:15 ` [ck] " Jens Bergmann

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=20040712231406.427caa2a.akpm@osdl.org \
    --to=akpm@osdl.org \
    --cc=ck@vds.kolivas.org \
    --cc=devenyga@mcmaster.ca \
    --cc=kernel@kolivas.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=wli@holomorphy.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