From owner-freebsd-arch Mon Jan 6 12: 7:32 2003 Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BF3BF37B401 for ; Mon, 6 Jan 2003 12:07:30 -0800 (PST) Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4FCD843E4A for ; Mon, 6 Jan 2003 12:07:29 -0800 (PST) (envelope-from bde@zeta.org.au) Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id HAA27132; Tue, 7 Jan 2003 07:07:02 +1100 Date: Tue, 7 Jan 2003 07:07:28 +1100 (EST) From: Bruce Evans X-X-Sender: bde@gamplex.bde.org To: Julian Elischer Cc: Jake Burkholder , Subject: Re: uarea/kstack/pcb/swapout sillyness In-Reply-To: Message-ID: <20030107061643.F4486-100000@gamplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Mon, 6 Jan 2003, Julian Elischer wrote: > I didn't see the beginning of this in -arch.. was it there? Yes. Jake quoted all of my original message. > the u-area handling ahs not changed since threads were introduced. > whether they are swapped /not-swapped is the same. > it is supposedly swapped out in: > vm/vm_glue.c > in vm_proc_swapout(struct proc *p) > > the thread is swapped out as mentionned below > in: pmap_swapout_thread. > > It is a pitty that they are not in the same location, but as Jake said. > the thread stack (including the PCB) turns out to be somewhat MD. Yes. I missed the thread swapout call, having been misled partly by the rss calculation not counting swapped out stack pages. From kern_proc.c: % kp->ki_rssize = vmspace_resident_count(vm); /*XXX*/ % if (p->p_sflag & PS_INMEM) % kp->ki_rssize += UAREA_PAGES; % FOREACH_THREAD_IN_PROC(p, td) /* XXXKSE: thread swapout check */ % kp->ki_rssize += KSTACK_PAGES; There seems to be no need for the XXXKSE, except we should only count the stack pages if we aren't swapped out. PS_INMEM tells us if the stack pages are swapped out too, since we swap out the stack pages for all threads iff we swap out the upages (more precisely, it tells us if all these pages are swappable). > On Mon, 6 Jan 2003, Jake Burkholder wrote: > > > Apparently, On Mon, Jan 06, 2003 at 10:42:50PM +1100, > > Bruce Evans said words to the effect of; > > > I use "options NO_SWAPPING" to prevent swapping of upages, and would > > > like to make this the default and later remove its code and merge the > > > structs. Swapping of upages seems to be least useful on large systems > > > where it would save the most memory, since such systems might actually > > > want to spend time running the processes instead of swapping the them > > > see the long message for the commit that introduced NO_SWAPPING in 1996). > > > With today's larger memories and bloated processes and kernel stacks, > > > I think the space/time savings (positive or negative) don't matter and > > > we just have useless complications to swap upages. > > > > Agree. The stuff in the uarea should be allocated normally and hung > > off of struct proc. > > That is not a bad idea. It just depends on whether we want to swap that > 1 page or not. We left it "as it was" specifically because it was > swapped before so we swap it now.. Unfortunately for my argument, it's relatively easy to swap that 1 pages if we swap the stack pages (the infrastructure is much the same for both). Allocating the uarea normally simplifies some things but mostly not swapping. > > Wether or not swapping kernel stacks is still useful I don't really know. > > Well they are bigger, and a process might have quite a few of them. > A process with 10 suspended threads, each or 3 pages would be 30 pages > or 120KB. It's a judgement call I guess. I'm sure there are strange process mixes that could benefit from swapping 120KB per process, but I think they must be very uncommon now. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message