From owner-freebsd-current  Thu Oct 29 12:17:24 1998
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id MAA15855
          for freebsd-current-outgoing; Thu, 29 Oct 1998 12:17:24 -0800 (PST)
          (envelope-from owner-freebsd-current@FreeBSD.ORG)
Received: from highwind.com (hurricane.highwind.com [209.61.45.50])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA15849
          for <current@FreeBSD.ORG>; Thu, 29 Oct 1998 12:17:22 -0800 (PST)
          (envelope-from info@highwind.com)
Received: (from info@localhost)
	by highwind.com (8.8.6/8.8.6) id PAA02026;
	Thu, 29 Oct 1998 15:16:40 -0500 (EST)
Date: Thu, 29 Oct 1998 15:16:40 -0500 (EST)
Message-Id: <199810292016.PAA02026@highwind.com>
From: HighWind Software Information <info@highwind.com>
To: eischen@vigrid.com
CC: current@FreeBSD.ORG, eischen@vigrid.com, lists@tar.com
In-reply-to: <199810291610.LAA11080@pcnet1.pcnet.com> (message from Daniel
	Eischen on Thu, 29 Oct 1998 11:10:06 -0500 (EST))
Subject: Re: Thread Scheduler bug
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG


   > Possibly the VTALRM timer measures only time spent in user mode
   > and not in kernel mode.  This heavy I/O takes place almost entirely
   > in kernel mode and it is the only process running.  Therefore, very
   > little user time is being accumulated.  
   > 
   > Possibly it you waited long enough, you'd still get the SIGVTALRM.
   > If you add some user mode processing to the thread, you'll see
   > the SIGVTALRM sooner.

   Yeah, I just figured this out (should pay closer attention to
   the man pages).  Seems like the profiling timer would be closer
   to what we'd want (not to say the threads library should use
   the profiling timer).  A quick hack to replace occurrences of
   SIGVTALRM with SIGPROF in the threads library seems to make
   the test program work more correctly.

Interesting analysis. This seems to be a very NASTY problem.  If you
have a collection of threads that spend a lot of time in system space,
you can REALLY starve other threads. I can't imagine that this is a
rare occurance.

Is using SIGPROF a viable alternative? Sounds a bit drastic.

-Rob

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message