NetBSD Problem Report #12371

Received: (qmail 12659 invoked from network); 10 Mar 2001 08:12:27 -0000
Message-Id: <20010310081224.1533.qmail@primenet.com.au>
Date: 10 Mar 2001 19:12:23 +1100
From: mason@primenet.com.au
Reply-To: mason@primenet.com.au
To: gnats-bugs@gnats.netbsd.org
Subject: swapctl -U (or -d ...) doesn't update process information
X-Send-Pr-Version: 3.95

>Number:         12371
>Category:       kern
>Synopsis:       swapctl -U (or -d ...) doesn't update process information
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Mar 10 08:13:00 +0000 2001
>Closed-Date:    
>Last-Modified:  Sun Mar 18 23:31:01 +0000 2001
>Originator:     Geoff C. Wing
>Release:        20010309
>Organization:
Geoff Wing : <gcw@pobox.com>
Rxvt Stuff : <gcw@rxvt.org>
Zsh Stuff  : <gcw@zsh.org>
>Environment:
System: NetBSD c.primenet.com.au 1.5S NetBSD 1.5S (C) #0: Fri Mar 9 16:48:02 EST 2001 mason@c.primenet.com.au:/usr/netbsd/src/sys/arch/i386/compile/C i386
Architecture: i386
Machine: i386
>Description:
	When a "swapctl -U" is issued, pages are swapped back in.  But "ps"
	and "top" still indicate processes as swapped out.  Maybe this is
	because the text parts are unloaded still, though "rss" from "ps"
	(or "RES" from "top") is still giving a base number.
	# swapctl -U
	% ps 744 -u
	USER   PID %CPU %MEM VSZ RSS TT STAT STARTED    TIME COMMAND
	mason  744  0.0  0.0 400   4 p0 IWs+       - 0:00.00 zsh

	So why isn't all the memory this process has malloc()d being
	presented here?

>How-To-Repeat:
	obvious
>Fix:
	?
>Release-Note:
>Audit-Trail:

From: Chuck Silvers <chuq@chuq.com>
To: mason@primenet.com.au
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: kern/12371: swapctl -U (or -d ...) doesn't update process information
Date: Sun, 18 Mar 2001 07:58:25 -0800

 the number reported for "RSS" just an approximation of reality.
 it reflects the number of pages in the process which can be accessed
 without invoking the high-level VM code to resolve a page fault.
 normally that's close enough to the number of pages resident, since
 the way that pages are usually brought into memory is via that same
 VM page fault processing, and the results of that fault processing
 are cached for that process.  but when we bring pages into memory
 via another mechanism (in this case via swapctl), the VM system
 doesn't bother to figure out which processes are referencing the page,
 so the per-process RSS values don't change.  it would be possible
 to keep all the RSS values completely updated, but that would hurt
 performance, and more accurate RSS numbers aren't important enough
 to sacrifice any performance to get.

From: Geoff Wing <gcw@pobox.com>
To: Chuck Silvers <chuq@chuq.com>
Cc: gnats-bugs@gnats.netbsd.org
Subject: Re: kern/12371: swapctl -U (or -d ...) doesn't update process information
Date: Mon, 19 Mar 2001 10:30:05 +1100

 Chuck Silvers wrote about Re: kern/12371: swapctl -U (or -d ...) doesn't update process information:
 [...description of RSS elided...]

 That's fair enough.  Perhaps this bug-report should (unofficially) change
 to a (low priority) doc change-request for ps(1), top(1) and systat(1)
 to indicate that (unless there's a more appropriate area).
 (And kern/12371 can be closed)

 Regards,
 Geoff
>Unformatted:

Home	PR Database Search