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:Julian Elischer (jul@elischer.org)
Date:Nov 10, 2004 9:59:53 pm
List:org.freebsd.freebsd-arch

Scott Long wrote:

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.

We've been slowly working towards this.. when we moved the pcb out to the thread this became inevitable..

go for it!

Go for it! Just get some validation that amd64 and sparc64 work, and then do the deed. I'll try testing at least amd64 right now.