From owner-cvs-all Mon Jan 15 11:47:43 2001 Delivered-To: cvs-all@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id 1937037B400; Mon, 15 Jan 2001 11:47:14 -0800 (PST) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id f0FJjj191215; Mon, 15 Jan 2001 11:45:46 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Mon, 15 Jan 2001 11:47:17 -0800 (PST) From: John Baldwin To: Bruce Evans Subject: Re: cvs commit: src/sys/i386/conf GENERIC Cc: cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org, Wilko Bulte , Poul-Henning Kamp , Peter Wemm Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 15-Jan-01 Bruce Evans wrote: > On Sun, 14 Jan 2001, Peter Wemm wrote: > > That's because 5.0 serious sucks on all hardware :-). Developers should > occasionally develop on 386's so that it runs well on all systems. > >> In fact, it was near impossible to run on a 486-33 w/ 12MB ram when I tried >> it about 12 months ago on what was then -current. I was eventually able to > > Hmm. Matt and I fixed running with 5-6MB about 12 months ago. vfs_bio.c > had rotted sizing heuristics that prevented even booting with about 8MB. > I tested -current on a 486 with 16MB a couple of months ago. It was "only" > about 40% slower than it used to be for cpu-intensive things in the kernel. > >> The bottom line is that I feel the time is just about right to yank i386 >> entirely, not just taking it out of GENERIC. But I wont push for that >> (yet :-). But ending the expensive runtime cost of i386 support in >> GENERIC is well overdue I feel. The cost of slowing down copyin()/copyout() >> etc is just not worth it. > > The cost of slowing down copyin()/copyout() is essentially zero, since it is > just the cost of an indirect jump. The only significant slowdown used to be > from not using bswap. The "slowdowns" in the i386 mutex code seem to be > negative since the code is simplistic and uses plain movl's instead of > cmpxchg's. Maintaining this code working is the main cost. So are you ready to write the code in trap() to handle an illegal instruction fault in userland that decodes and executes all variants of cmpxchg? The new threading code in libc will be using atomic_cmpset() from userland, which is going to be the main hurdle to get over. > Bruce -- John Baldwin -- 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