NetBSD Problem Report #38792

From martin@duskware.de  Thu May 29 23:39:22 2008
Return-Path: <martin@duskware.de>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by narn.NetBSD.org (Postfix) with ESMTP id 5FD9463B8BC
	for <gnats-bugs@gnats.netbsd.org>; Thu, 29 May 2008 23:39:22 +0000 (UTC)
Message-Id: <20080529233552.9556B63B8BC@narn.NetBSD.org>
Date: Thu, 29 May 2008 23:35:52 +0000 (UTC)
From: ad@netbsd.org
Reply-To: ad@netbsd.org
To: netbsd-bugs-owner@NetBSD.org
Subject: sched_pstats takes too long
X-Send-Pr-Version: www-1.0

>Number:         38792
>Category:       kern
>Synopsis:       sched_pstats takes too long
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    rmind
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu May 29 23:40:00 +0000 2008
>Closed-Date:    Fri Apr 16 03:28:59 +0000 2010
>Last-Modified:  Fri Apr 16 03:28:59 +0000 2010
>Originator:     Andrew Doran
>Release:        4.99.63
>Organization:
The NetBSD Project
>Environment:
n/a/
>Description:
sched_pstats() can take a long time if there are thousands of procs/LWPs
in the system.

That's a problem because it runs in interrupt context, and because 
realtime threads might need access to the process list.

>How-To-Repeat:
Testing.
>Fix:
Maybe:

- Make sched_pstats use a marker process so it does not hold proc_lock
  for so long?

- Have two classes of callout, like Solaris. One run from a softint
  as we do now, and another run from a kthread, for slow items like
  sched_pstats.

>Release-Note:

>Audit-Trail:
From: Jason Thorpe <thorpej@shagadelic.org>
To: gnats-bugs@NetBSD.org
Cc: kern-bug-people@netbsd.org,
 gnats-admin@netbsd.org,
 netbsd-bugs@netbsd.org
Subject: Re: kern/38792: sched_pstats takes too long
Date: Thu, 29 May 2008 16:44:15 -0700

 On May 29, 2008, at 4:40 PM, ad@netbsd.org wrote:

 >> Maybe:
 >
 > - Make sched_pstats use a marker process so it does not hold proc_lock
 >  for so long?
 >
 > - Have two classes of callout, like Solaris. One run from a softint
 >  as we do now, and another run from a kthread, for slow items like
 >  sched_pstats.


 ...or restructure the scheduler so that you never have to pass over  
 all of the processes periodically?

 -- thorpej

From: Mindaugas Rasiukevicius <rmind@NetBSD.org>
To: ad@NetBSD.org
Cc: gnats-bugs@NetBSD.org
Subject: Re: kern/38792: sched_pstats takes too long
Date: Mon, 2 Jun 2008 22:08:34 +0100

 Hello,

 > >Number:         38792
 > >Category:       kern
 > >Synopsis:       sched_pstats takes too long

 > >Fix:
 > Maybe:
 > 
 > - Make sched_pstats use a marker process so it does not hold proc_lock
 >   for so long?
 > 
 > - Have two classes of callout, like Solaris. One run from a softint
 >   as we do now, and another run from a kthread, for slow items like
 >   sched_pstats.

 Sorry, what do you mean by "marker process"?

 Hmm.. I have noticed that some calculations could be lockless.

 -- 
 Best regards,
 Mindaugas
 www.NetBSD.org

From: Mindaugas Rasiukevicius <rmind@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/38792 CVS commit: src/sys
Date: Fri, 16 Apr 2010 03:21:50 +0000

 Module Name:	src
 Committed By:	rmind
 Date:		Fri Apr 16 03:21:49 UTC 2010

 Modified Files:
 	src/sys/kern: kern_synch.c
 	src/sys/sys: sched.h
 	src/sys/uvm: uvm_extern.h uvm_glue.c uvm_meter.c

 Log Message:
 - Merge sched_pstats() and uvm_meter()/uvm_loadav().  Avoids double loop
   through all LWPs and duplicate locking overhead.

 - Move sched_pstats() from soft-interrupt context to process 0 main loop.
   Avoids blocking effect on real-time threads.  Mostly fixes PR/38792.

 Note: it might be worth to move the loop above PRI_PGDAEMON.  Also,
 sched_pstats() might be cleaned-up slightly.


 To generate a diff of this commit:
 cvs rdiff -u -r1.280 -r1.281 src/sys/kern/kern_synch.c
 cvs rdiff -u -r1.71 -r1.72 src/sys/sys/sched.h
 cvs rdiff -u -r1.162 -r1.163 src/sys/uvm/uvm_extern.h
 cvs rdiff -u -r1.144 -r1.145 src/sys/uvm/uvm_glue.c
 cvs rdiff -u -r1.51 -r1.52 src/sys/uvm/uvm_meter.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

Responsible-Changed-From-To: kern-bug-people->rmind
Responsible-Changed-By: rmind@NetBSD.org
Responsible-Changed-When: Fri, 16 Apr 2010 03:28:59 +0000
Responsible-Changed-Why:


State-Changed-From-To: open->closed
State-Changed-By: rmind@NetBSD.org
State-Changed-When: Fri, 16 Apr 2010 03:28:59 +0000
State-Changed-Why:
Fixed.


>Unformatted:

Home	PR Database Search