public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Dimitri Sivanich <sivanich@sgi.com>
To: "Paul E. McKenney" <paulmck@us.ibm.com>,
	Dipankar Sarma <dipankar@in.ibm.com>, Ingo Molnar <mingo@elte.hu>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@osdl.org>
Subject: Large thread wakeup (scheduling) delay spikes
Date: Tue, 20 Dec 2005 09:17:22 -0600	[thread overview]
Message-ID: <20051220151722.GA357@sgi.com> (raw)

I posted something about this back in October, but received little response.
Maybe others have run into problems with this since then.

I've noticed much less deterministic and more widely varying thread wakeup
(scheduling) delays on recent kernels.  Even with isolated processors, the
maximum delay to wakeup has gotten much longer (configured with or without
CONFIG_PREEMPT).

The maximum delay to wakeup is now more than 10x longer than it was in
2.6.13.4 and previous kernels, and that's on isolated processors (as much
as 300 usec on a 1GHz cpu), although nominal values remain largely unchanged.
The latest version I've tested is 2.6.15-rc5.

Delving into this further I discovered that this is due to the execution
time of file_free_rcu(), running from rcu_process_callbacks() in ksoftirqd.
It appears that the modification that caused this was:
	http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=ab2af1f5005069321c5d130f09cce577b03f43ef

By simply making the following change things return to more consistent
thread wakeup delays on isolated cpus, similiar to what we had on kernels
previous to the above mentioned mod (I know this change is incorrect,
it is just for test purposes):

fs/file_table.c
@@ -62,7 +62,7 @@
 
 static inline void file_free(struct file *f)
 {
-       call_rcu(&f->f_rcuhead, file_free_rcu);
+       kmem_cache_free(filp_cachep, f);
 }
 

I am wondering if there is some way we can return to consistently fast
and predictable scheduling of threads to be woken?  If not on the
system in general, maybe at least on certain specified processors?

Dimitri

             reply	other threads:[~2005-12-20 15:17 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-20 15:17 Dimitri Sivanich [this message]
2005-12-21 13:38 ` Large thread wakeup (scheduling) delay spikes Paul E. McKenney
2005-12-21 14:43   ` Dimitri Sivanich

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=20051220151722.GA357@sgi.com \
    --to=sivanich@sgi.com \
    --cc=akpm@osdl.org \
    --cc=dipankar@in.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=paulmck@us.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