Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 15 Jan 2001 11:47:17 -0800 (PST)
From:      John Baldwin <jhb@FreeBSD.org>
To:        Bruce Evans <bde@zeta.org.au>
Cc:        cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org, Wilko Bulte <wkb@freebie.demon.nl>, Poul-Henning Kamp <phk@critter.freebsd.dk>, Peter Wemm <peter@netplex.com.au>
Subject:   Re: cvs commit: src/sys/i386/conf GENERIC
Message-ID:  <XFMail.010115114717.jhb@FreeBSD.org>
In-Reply-To: <Pine.BSF.4.21.0101152207200.16706-100000@besplex.bde.org>

next in thread | previous in thread | raw e-mail | index | archive | help

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 <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.010115114717.jhb>