NetBSD Problem Report #5666

Received: (qmail 6192 invoked from network); 26 Jun 1998 23:11:48 -0000
Message-Id: <199806262258.PAA00649@jaws.nas.nasa.gov>
Date: Fri, 26 Jun 1998 15:58:12 -0700 (PDT)
From: Jason R Thorpe <thorpej@nas.nasa.gov>
Reply-To: thorpej@netbsd.org
To: gnats-bugs@gnats.netbsd.org
Subject: arm32 pmap does not free PTs once all mappings are removed
X-Send-Pr-Version: 3.95

>Number:         5666
>Category:       port-arm
>Synopsis:       arm32 pmap does not free PTs once all mappings are removed
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    bjh21
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Jun 26 16:20:00 +0000 1998
>Closed-Date:    Mon Mar 22 11:25:42 +0000 2004
>Last-Modified:  Mon Mar 22 11:25:42 +0000 2004
>Originator:     
>Release:        19980626
>Organization:
Numerical Aerospace Simulation Facility - NASA Ames
>Environment:

System: NetBSD jaws 1.3F NetBSD 1.3F (JAWS) #1: Fri Jun 26 14:05:13 PDT 1998 thorpej@jaws:/tmp_mnt/dracul/u5/netbsd/src/sys/arch/arm32/compile/JAWS arm32


>Description:
	The arm32 pmap dynamically allocates level 2 page table pages when
	they are needed.  However, it does not track references to these
	tables.  This means that once all of the mappings are removed for
	a particular level 2 table, the page is not freed back to the system,
	until the pmap is destroyed, when the process exits.

	This is a problem if the system goes into a desperate memory
	condition, and begins to swap out processes.  When a process
	is swapped out, the VM system calls pmap_collect() with that
	process's pmap, so that the pmap module can free resources in
	use by that pmap.  Since the pmap module is allowed to "forget"
	mappings for a map at any time, it would be able to pmap_remove()
	the entire user address space of that pmap, thus freeing up the
	level 2 PT pages.  However, since pmap_remove() doesn't free those
	pages back, doing so is useless.

	For an example of how this is done, take a look at the NetBSD/alpha
	pmap module: src/sys/arch/alpha/alpha/pmap.c.

>How-To-Repeat:
	I managed to tickle this by doing a few parallel kernel builds on
	my 32M Shark.  Eventually, the pmap module died because no more
	free pages were available.  It should have been able to hobble
	along a little longer if pages were freed up as it began to swap
	out processes.

>Fix:
	An implementation that tracks PT page references and removes
	mappings (thus freeing pages to the system) in pmap_collect()
	can be found at: src/sys/arch/alpha/alpha/pmap.c.  This could
	be used as an example of how to implement it for the arm32 pmap.
>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->analyzed 
State-Changed-By: mark 
State-Changed-When: Sat Jun 27 12:38:51 PDT 1998 
State-Changed-Why:  
The problem is recognised and understood. Implementation of a solution
is in progress. 

Responsible-Changed-From-To: gnats-admin->port-arm32-maintainer 
Responsible-Changed-By: fair 
Responsible-Changed-When: Mon Dec 28 09:35:29 PST 1998 
Responsible-Changed-Why:  
This PR is the responsibility of the portmaster, 
not the GNATS database administrator. 

Responsible-Changed-From-To: port-arm32-maintainer->port-arm-maintainer 
Responsible-Changed-By: bjh21 
Responsible-Changed-When: Sat Mar 10 10:53:51 PST 2001 
Responsible-Changed-Why:  
The arm32 pmap module is now in sys/arch/arm. 

Responsible-Changed-From-To: port-arm-maintainer->chris 
Responsible-Changed-By: chris 
Responsible-Changed-When: Thu Aug 9 02:32:42 PDT 2001 
Responsible-Changed-Why:  
I'm working on the pmap at the moment, and this is somewhere on
the list of things to sort out.

State-Changed-From-To: analyzed->feedback 
State-Changed-By: chris 
State-Changed-When: Sat Apr 26 20:11:36 UTC 2003 
State-Changed-Why:  
There is now a new arm32 pmap option which while adding other improvements also fixes this PR. 
State-Changed-From-To: feedback->closed 
State-Changed-By: bjh21 
State-Changed-When: Mon Mar 22 11:24:36 UTC 2004 
State-Changed-Why:  
PR has been in "feedback" state for over three months. 


Responsible-Changed-From-To: chris->bjh21 
Responsible-Changed-By: bjh21 
Responsible-Changed-When: Mon Mar 22 11:24:36 UTC 2004 
Responsible-Changed-Why:  
I closed it. 
>Unformatted:

Home	PR Database Search