Date: Mon, 6 Jan 2003 10:24:58 -0800 (PST) From: Julian Elischer <julian@elischer.org> To: Jake Burkholder <jake@locore.ca> Cc: Bruce Evans <bde@zeta.org.au>, arch@FreeBSD.ORG Subject: Re: uarea/kstack/pcb/swapout sillyness Message-ID: <Pine.BSF.4.21.0301061013580.4845-100000@InterJet.elischer.org> In-Reply-To: <20030106130058.B96446@locore.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
I didn't see the beginning of this in -arch.. was it there?
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.
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;
>
> > Kernel stack pages don't seem to be handled by vm_proc_swap{in,out}.
> > Only the upages are swapped. This makes having a user area separate
> > from the proc struct even less useful than it used to be. We have
> > considerable complications to support the dubious feature of swapping
> > the user area. Swapping it out saves a whole 1 page per process
> > (UAREA_PAGE is 1 for all arches). OTOH, we don't bother swapping out
> > the much larger kernel stacks. There are 4 pages per stack on some
> > arches and there may be multiple stacks per process (1 per thread).
> >
> > Having a separate user area actually wastes memory in the usual (?)
> > case where the user area is not swapped. The user area now contains
> > only struct sigacts, which has size 2688, and struct pstats, which
> > has size 224, so 4096 - 2688 - 224 = 1184 bytes per process is wasted
> > for the struct (not counting costs for indirections).
>
> The kernel stack pages are still handled in MD code, due to the fact
> that ia64 uses contigmalloc to allocate them, but they are/will still
> be swapped. pmap_swapout_thread is called by swapout() on each thread
> in a process after swapping out the uarea.
>
> >
> > There seems to be even less point to keeping the pcb separate from
> > the thread struct. It saves space only by stealing stack space,
> > and costs indirections. Some PS_INMEM checks are now bogus because
> > the pcb is not in the user area so it doesn't get swapped.
> >
> > 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..
>
> 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.
>
> Jake
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-arch" in the body of the message
>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0301061013580.4845-100000>