Date: Sun, 23 May 1999 11:37:40 +0800 From: Peter Wemm <peter@netplex.com.au> To: Bruce Evans <bde@zeta.org.au> Cc: dima@tejblum.dnttm.rssi.ru, freebsd-current@FreeBSD.ORG Subject: Re: calcru and upages Message-ID: <19990523033740.841F922@overcee.netplex.com.au> In-Reply-To: Your message of "Sun, 23 May 1999 12:45:47 %2B1000." <199905230245.MAA13333@godzilla.zeta.org.au>
next in thread | previous in thread | raw e-mail | index | archive | help
Bruce Evans wrote: > >calcru() access p_stats, which is in upages. Therefore, as I understand, > >it should not be called on a swapped out process. Neither calcru() nor > > Does anyone object to moving everything except the stack from the upages > to the proc table? > > Bruce Well, we have three things that are about the same size: struct pcb u_pcb; 240 bytes struct sigacts u_sigacts; 292 bytes struct pstats u_stats; 248 bytes On the other hand: sizeof (struct proc) = 328 bytes. the pcb contains a heap of space for the FP state. It accounts for 176 of the 240 bytes, leaving 64-odd bytes left for the pcb proper. The ldt pointers need to move to proc scope for rfork()/clone(), and gc'ing a few things that can get it as low as 40 - 48 bytes. pcb_savefpu has padding in case a FPU emulator is used and is actually smaller than 176 bytes, and could be changed depending on whether it's a real or emulated fpu. IMHO, I'd move them to reference counted malloc'ed structs since sigacts needs to be shared for clone/rforked processes. I think there is also benefit to having the sigacts at least malloced, one day we should be able to extend the signals beyond the existing 32 set, at least for the 32 extra RT signals. I personally would love to see this come out of the upages, it makes tracking through a stack overflow even harder. We could put an unmapped red-line page below the bottom stack page to ensure we get a double fault on an overflow instead of mystery corruptions etc. I also think it's a step closer towards seperating thread context vs. process context. Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990523033740.841F922>