:> 
:>     I don't know what your setup is, Kent, but when I do a buildworld
:>     my system is 95% cpu bound, with virtual no idle time at all.  It's
:>     all going to the buildworld.  On both 3.x and 4.x.
:
:It is on 4.x but it wasn't on 3.4. At least, seti was taking time that
:it shouldn't have been getting.

    Right.  I think we're in agreement, it's just getting lost somewhere :-)

:>     (For 3.x)
:> 
:>         CFLAGS= -O2 -pipe
:> 
:>     (For 4.x)
:> 
:>         CFLAGS= -Os -pipe
:
:I am trying this right now. I thought that optimizing this way was
:dangerous for the kernel. The problem for the new people is what works
:and when. You have to understand that Murphy sits on my shoulder. If
:there are 2+ bugs in a product, I will eventually end up seeing one of
:them :).

    -O2 and -Os are 'safe'.  Other optimization levels (-O3 for example)
    are *NOT* safe.  Most machine-specific optimizations (-m options) should
    generally be considered NOT safe.

:I have been going to turn on softupdates but haven't got there yet. I
:want to link /usr/obj to the scsi drive first. Then, I think I will
:try softupdates. Try the worst combo's first and then add features but
:write the times down when you try the different arrangements. 
:...
:Kent

    I also turn off atime updates ('noatime' mount option in /etc/fstab)
    on /usr/src, since buildworlds do a lot of file scanning and there
    is simply no reason to update every single file's inode with a new
    atime.   I doubt it makes much of a difference but it does leave
    more clean buffer cache buffers available for other things.

    -pipe makes a significant difference since without it every source
    file being compiled creates several files in /tmp.  Softupdates makes
    a significant difference in its ability to asynchronize file creation
    and meta-data updates (which helps /tmp as well as /usr/obj, though
    /tmp is helped even more by using -pipe).

                                        -Matt
                                        Matthew Dillon 
                                        <[EMAIL PROTECTED]>



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Reply via email to