atom feed14 messages in org.freebsd.freebsd-archU Area Removal
FromSent OnAttachments
David SchultzNov 10, 2004 7:00 pm 
Scott LongNov 10, 2004 7:15 pm 
Brian Fundakowski FeldmanNov 10, 2004 7:16 pm 
Bruce M SimpsonNov 10, 2004 7:32 pm 
Scott LongNov 10, 2004 7:44 pm 
David SchultzNov 10, 2004 7:56 pm 
Julian ElischerNov 10, 2004 9:59 pm 
Marcel MoolenaarNov 10, 2004 11:53 pm 
John BaldwinNov 11, 2004 9:28 am 
Scott LongNov 11, 2004 4:16 pm 
David SchultzNov 11, 2004 5:01 pm 
Marcel MoolenaarNov 11, 2004 7:51 pm 
Scott LongNov 11, 2004 10:26 pm 
Matthew DillonNov 13, 2004 6:19 pm 
Subject:U Area Removal
From:Scott Long (sco@freebsd.org)
Date:Nov 11, 2004 4:16:57 pm
List:org.freebsd.freebsd-arch

David Schultz wrote:

Over the years, the amount of data we have stored in each process' U area has eroded to the point where all we have left are the following:

- A struct kinfo_proc that is only used for a.out core dumps. This can be reconstructed at the time of the core dump, so it doesn't need to be there.

- The struct pstats for the process, which takes a mere 216 bytes on i386.

In exchange for the ability to swap out this 216-byte structure, we keep around a 4096-byte page, a 132-byte vm_object, and a couple of pointers. Moreover, there is a small amount of runtime overhead associated with this, and developers need to remember to PHOLD() and PRELE() the process as appropriate.[1]

I propose to remove the ability to swap the U area, allocating p_stats from malloced memory instead. Medium-term scheduling and swapping of kernel stacks would be retained. Here are the patches; !i386 testers wanted:

http://www.freebsd.org/~das/patches/upages.diff

[1] Most of the instances of PHOLD() and PRELE() right now never needed to be there or have been unnecessary ever since the PCB was moved out of the U area.

This breaks amd64 in bad ways on boot. I'll send a trace and more info when I get a serial console hooked up.

Scott