Date: Sat, 01 Sep 2001 13:22:13 -0700 (PDT) From: John Baldwin <jhb@FreeBSD.org> To: Matt Dillon <dillon@earth.backplane.com> Cc: cvs-all@FreeBSD.ORG, cvs-committers@FreeBSD.ORG, Peter Wemm <peter@wemm.org> Subject: Re: cvs commit: src/sys/kern subr_prof.c kern_ntptime.c kern_xxx Message-ID: <XFMail.010901132213.jhb@FreeBSD.org> In-Reply-To: <200109010827.f818RW370778@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 01-Sep-01 Matt Dillon wrote: > Believe me, I know these patches are breaking the P4 merge and also > playing havoc with Alfred's and JHB's stuff. I'm not doing it on > purpose. Frankly, I'm surprised that not one person beyond Alfred has > done any Giant pushdown work on the syscalls since I added the MPSAFE > flag to the syscall generator months and months ago. Well, it needs > to be done. Actually, p4 handles 3-way merges quite well. It probably won't step on my toes very much. > I'm also annoyed that so much incremental work is being done in P4 rather > then in the main tree. Julian's KSE stuff is an all-or-nothing deal > and P4 makes sense for a little while, but neither the proc lock, or > the struct filedesc stuff, or the struct file stuff is all-or-nothing... > it can all be done incrementally direct to the main tree as long as > you test the resulting kernel before you commit it. Instead I'm seeing > a kitchen-sink approach being taken when it is entirely unnecessary... > we have Giant available, it makes taking an incremental approach > possible! Mostly because I haven't done more than compile my current set of proc locking changes. I'm using p4 to store work revisions of files before I can test them and commit them. Presently I'm running into a wall with a seemingly simply change wrt proc locking and sendsig causing an Alpha SMP kernel to blow up my dual Alpha test machine but work fine on my UP alpha test machine. > Also, since I'm in critique mode... for gods sake, LAY OFF THE > MULTI-LINE MACROS AND INLINES FOR COMMON PROCEDURE CALLS!! The bloat > they are causing is unbelievable. Do take into account the difference that having debugging on makes. A debugging kernel is going to be bloated, yes, but the non-debugging one won't be. Other OS's with multithreaded kernels inline the simple first test for mutex acquire/releases to optimize for the common case. > -Matt -- John Baldwin <jhb@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.010901132213.jhb>