speed up port compiling using RAM (tmpfs) ???
Hi, I am curious to know if there is a way to compile a port such as X11 or KDE faster. I know in Gentoo, you can mount a part of RAM and compile in that. This substantially decreases the compile time. Reference: http://gentoo-wiki.com/TIP_Speeding_up_portage_with_tmpfs Does anyone know how to do this in Freebsd? -- Ashok Shrestha ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Taking a process of the runqueue.
Hello, How can i take a process of the runqueue ? i do not want that process and contained threads to be scheduled for some time.Then i may again put that process in the runqueue. TIA. Regards, Anupam ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: speed up port compiling using RAM (tmpfs) ???
On Sun, Jan 15, 2006 at 02:45:30AM -0500, Ashok Shrestha wrote: Hi, I am curious to know if there is a way to compile a port such as X11 or KDE faster. I know in Gentoo, you can mount a part of RAM and compile in that. This substantially decreases the compile time. Reference: http://gentoo-wiki.com/TIP_Speeding_up_portage_with_tmpfs Does anyone know how to do this in Freebsd? You should take a look at mdconfig(8) and ports(7). With mdconfig you create the ram-based disk and with WRKDIRPREFIX you tell the ports to use that disk instead of the default workdir. -- La prueba mas fehaciente de que existe vida inteligente en otros planetas, es que no han intentado contactar con nosotros. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: speed up port compiling using RAM (tmpfs) ???
日曜日 15 1月 2006 16:45、Ashok Shrestha さんは書きました: Hi, I am curious to know if there is a way to compile a port such as X11 or KDE faster. I know in Gentoo, you can mount a part of RAM and compile in that. This substantially decreases the compile time. Reference: http://gentoo-wiki.com/TIP_Speeding_up_portage_with_tmpfs Does anyone know how to do this in Freebsd? Sure. Read the ports(7) man page paying special attention to the WRKDIRPREFIX variable. Then man mount_mfs and mdconfig. Those should do the trick. Eric -- The signature is a location used to give a personalised feel to each E-mail without having to personalise each E-mail. pgpEJMReFz5sW.pgp Description: PGP signature
Re: How priority propagation works on read/write lock?
On Sun, 15 Jan 2006, prime wrote: On 1/15/06, Tiffany Snyder [EMAIL PROTECTED] wrote: Does FreeBSD support rwlocks? ... FreeBSD supports sx now,see sx(9).sx has the same semanteme as rwlock. While semantically they are very simila, John Baldwin has a work-in-progress implementation of rwlock's in Perforce. Given the progress he appears to be making, I imagine we'll see it in CVS within a week or two. Robert N M Watson ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Taking a process of the runqueue.
On 2006-01-15 15:02, Anupam Deshpande [EMAIL PROTECTED] wrote: Hello, How can i take a process of the runqueue ? i do not want that process and contained threads to be scheduled for some time.Then i may again put that process in the runqueue. By sending a STOP signal to it? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: speed up port compiling using RAM (tmpfs) ???
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ashok Shrestha wrote: Hi, I am curious to know if there is a way to compile a port such as X11 or KDE faster. I know in Gentoo, you can mount a part of RAM and compile in that. This substantially decreases the compile time. Reference: http://gentoo-wiki.com/TIP_Speeding_up_portage_with_tmpfs Does anyone know how to do this in Freebsd? -- Ashok Shrestha You can also take a look at devel/ccache and devel/distcc from ports. - --niki -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFDym6JHNAJ/fLbfrkRAuV5AKCw01ZCh5/wmc5cBxXsY2NaOGCR6ACfc1VN 7Tx/hA8eUmS65P0Nf0tvF3Y= =uOVv -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: speed up port compiling using RAM (tmpfs) ???
you can mount a small memory filesystem think it's called mbfs or something and change the work dir to that then you should be able to compile KDE using ram instead of the HD -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ashok Shrestha wrote: Hi, I am curious to know if there is a way to compile a port such as X11 or KDE faster. I know in Gentoo, you can mount a part of RAM and compile in that. This substantially decreases the compile time. Reference: http://gentoo-wiki.com/TIP_Speeding_up_portage_with_tmpfs Does anyone know how to do this in Freebsd? -- Ashok Shrestha You can also take a look at devel/ccache and devel/distcc from ports. - --niki -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFDym6JHNAJ/fLbfrkRAuV5AKCw01ZCh5/wmc5cBxXsY2NaOGCR6ACfc1VN 7Tx/hA8eUmS65P0Nf0tvF3Y= =uOVv -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How priority propagation works on read/write lock?
That's awesome. Thanks for the update. Tiffany. On 1/15/06, Robert Watson [EMAIL PROTECTED] wrote: On Sun, 15 Jan 2006, prime wrote: On 1/15/06, Tiffany Snyder [EMAIL PROTECTED] wrote: Does FreeBSD support rwlocks? ... FreeBSD supports sx now,see sx(9).sx has the same semanteme as rwlock. While semantically they are very simila, John Baldwin has a work-in-progress implementation of rwlock's in Perforce. Given the progress he appears to be making, I imagine we'll see it in CVS within a week or two. Robert N M Watson ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Panic in nfs_putpages() on 6-stable.
I've run into this panic a couple of times over the last few days, while trying to rebuild ports using an NFS-mounted /usr/ports filesystem. It happened again today and this time I had time to look at the dump. The problem is a null pointer dereference in nfs_putpages(), when it tries to look at np-n_size. It turns out that v_data is NULL on entry to this routine. Looking at the stack I see why: #6 0xc0674e4a in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #7 0xc05eb030 in nfs_putpages (ap=0xe81c6a14) at /usr/src/sys/nfsclient/nfs_bio.c:301 #8 0xc0691148 in VOP_PUTPAGES_APV (vop=0x1000, a=0xe81c6a14) at vnode_if.c:2164 #9 0xc064fd8e in vnode_pager_putpages (object=0xcafaa840, m=0x1000, count=0x1000, sync=0x5, rtvals=0x1000) at vnode_if.h:1119 During symbol reading, Attribute value is not a constant (DW_FORM_ref4). #10 0xc064b99e in vm_pageout_flush (mc=0xe81c6ab0, count=0x1, flags=0x5) at vm_pager.h:147 #11 0xc0647d0c in vm_object_page_collect_flush (object=0xcafaa840, p=0xc19e5218, curgeneration=0x0, pagerflags=0x5) at /usr/src/sys/vm/vm_object.c:950 #12 0xc0647800 in vm_object_page_clean (object=0xcafaa840, start=0x0, end=Unhandled dwarf expression opcode 0x93 ) at /usr/src/sys/vm/vm_object.c:753 #13 0xc0647525 in vm_object_terminate (object=0xcafaa840) at /usr/src/sys/vm/vm_object.c:608 #14 0xc064e5ad in vnode_destroy_vobject (vp=0xcb58c110) at /usr/src/sys/vm/vnode_pager.c:166 #15 0xc05ee075 in nfs_reclaim (ap=0x1000) at /usr/src/sys/nfsclient/nfs_node.c:247 #16 0xc069095e in VOP_RECLAIM_APV (vop=0x1000, a=0xe81c6c90) at vnode_if.c:1589 #17 0xc0587aa5 in vgonel (vp=0xcb58c110) at vnode_if.h:818 #18 0xc0584ac2 in vlrureclaim (mp=0xc9b2e400) at /usr/src/sys/kern/vfs_subr.c:612 #19 0xc0584e8b in vnlru_proc () at /usr/src/sys/kern/vfs_subr.c:725 #20 0xc052034c in fork_exit (callout=0xc0584d00 vnlru_proc, arg=0x0, frame=0xe81c6d38) at /usr/src/sys/kern/kern_fork.c:789 #21 0xc0674eac in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:208 In nfs_reclaim(), just before he calls vnode_destroy_vobject(), he zfrees and clears vp-v_data. When, down in the guts of vm_object.c, he tries to flush the associated pages, v_data is already NULL so he goes boom. Now, why does he do the zfree/clear before vnode_destroy_vobject()? Is he assuming that there are no pages associated with this vnode that need to be flushed? Should there be? I looked at some other file systems and they do the same thing. The obvious fix is to move the zfree/clear to after the vnode_destroy_vobject() but if there should be no pages that need to be flushed on the vnode at this point, that would just hide the problem. I can keep looking at the code to answer my question but I thought I would ask here first, in case there's someone who knows the answer right away. Thanks. -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: speed up port compiling using RAM (tmpfs) ???
On Sunday 15 January 2006 18:15, Ashok Shrestha wrote: I am curious to know if there is a way to compile a port such as X11 or KDE faster. I know in Gentoo, you can mount a part of RAM and compile in that. This substantially decreases the compile time. Reference: http://gentoo-wiki.com/TIP_Speeding_up_portage_with_tmpfs Does anyone know how to do this in Freebsd? Make a RAM drive using mdconfig and the mount it somewhere. Then put WRKDIRPREFIX=/path/to/md in /etc/make.conf -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgp2RLZaVYRSf.pgp Description: PGP signature
giving more cpu time to cpu intensive kernel daemon
dear all, i created a kernel daemon thread using the SYSINIT(). i want that daemon thread to do more cpu intensive tasks and that's why i want to give it more cpu time. my daemon thread get a priority of -84 and a nice value of 0. i guess when the nice value is 0 it affects its scheduling. how could i give it a good nice value ? are there any other options that i may have to look upon to ensure the daemon gets more of the cpu time ?? thanks, kamal __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Panic in nfs_putpages() on 6-stable, more info.
A bit more data and another question. On Sun, 2006-01-15 at 12:40 -0800, Frank Mayhar wrote: In nfs_reclaim(), just before he calls vnode_destroy_vobject(), he zfrees and clears vp-v_data. When, down in the guts of vm_object.c, he tries to flush the associated pages, v_data is already NULL so he goes boom. Now, why does he do the zfree/clear before vnode_destroy_vobject()? Is he assuming that there are no pages associated with this vnode that need to be flushed? Should there be? I looked at some other file systems and they do the same thing. The obvious fix is to move the zfree/clear to after the vnode_destroy_vobject() but if there should be no pages that need to be flushed on the vnode at this point, that would just hide the problem. Looking further down, at vlrureclaim(), I see that the commentary for vlrureclaim() specifically says that a a flushed vnode may still have backing store, so it appears that yes, there may be pages associated with the vnode when he calls vgonel(). Between vgonel() and nfs_reclaim() there's just VOP stuff, so the flushing has to be done lower down. The nfs_reclaim() routine itself just does some bookkeeping and then calls vnode_destroy_vobject(). That routine can push pages out, which means that if the backing store is on NFS, nfs_putpages() can be called. But that routine will fault because he'll try to use v_data as an nfsnode. The reason for my confusion is that of the filesystems in the tree, the only one that doesn't zfree and clear v_data before calling vnode_destroy_vobject() is UFS. The commentary in ufs_reclaim() is clear, though: /* * Destroy the vm object and flush associated pages. */ vnode_destroy_vobject(vp); Then later he VI_LOCKS() and clears v_data. (And [indirectly] does the zfree only _after_ that, which is interesting but probably not important.) I'm going to go slightly out on a limb here and guess that the flush associated pages thing came in relatively recently and the other filesystems haven't caught up with it. This implies that the proper fix is to go through those other xxx_reclaim() routines and reorder the operations. That's easy enough to do, but I would like to make sure that my understanding of this (and my guess) is correct and that I'm not wasting my time. Thanks! -- Frank Mayhar [EMAIL PROTECTED] http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How priority propagation works on read/write lock?
you mean, boosting the priority of a reader would be required to avoid priority inversion, but difficult to implement? regards -kamal On 1/14/06, John Baldwin [EMAIL PROTECTED] wrote: I think you just kind of punt and do a best effort. Trying to manage a list of current read lock holders would be a bit PITA. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
