Re: speed up port compiling using RAM (tmpfs) ???
Ashok Shrestha [EMAIL PROTECTED] writes: 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? I doubt it would help. You get faster disk accesses, but significantly reduce the amount of memory available for the buffer cache. DES -- Dag-Erling Smørgrav - [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: tuning to run large (1000+) numbers of null_mounts
On Wed, 18 Jan 2006, Kris Kennaway wrote: hmmm...the cut and paste of that loud warning was from a 6.0-RELEASE man page ... if I need to be CURRENT to get the updated man page, do I also need to be CURRENT to get the safe null_mount code itself ? Or is 6.0-RELEASE safe ? (re: null_mount) Thanks a lot. 6.0-RELEASE is also safe. I only just removed the warning the other day, but I'll also be merging it to 6.0-STABLE. Ok, that is good to know. However, I continue to see instability on this system with the 2000+ null_mounts. Are there any system tunables / sysctls / kernel configurations that I should be studying or experimenting with that are relevant to this ? Perhaps looking more broadly, are there any tunables related to large numbers of mounted filesystems _period_, not just null mounts ? For what it is worth, the system also has several mdconfig'd and mounted snapshots (more than 5, less than 10). Further, all of the null mounts mount space from within a mounted snapshot into normal filesystem space. With all the snapshots mounted and all the null mounts mounted, I find that commencing an rsync from the filesystem that all these exist on locks up the machine. I can still ping it, but it refuses all connections. It requires a power cycle. Comments ? ___ 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) ???
Mike Meyer [EMAIL PROTECTED] writes: Will using a swap-backed disk change anything? Not really. How about the best way to configure things to use two disks for the compile? I'm not sure what you are trying to achieve. Unlike the base system, the ports tree does not use separate source and object directories. DES -- Dag-Erling Smørgrav - [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: speed up port compiling using RAM (tmpfs) ???
On Thu, Jan 19, 2006 at 05:54:02PM +0100, Dag-Erling Sm?rgrav wrote: Mike Meyer [EMAIL PROTECTED] writes: Will using a swap-backed disk change anything? Not really. How about the best way to configure things to use two disks for the compile? I'm not sure what you are trying to achieve. Unlike the base system, the ports tree does not use separate source and object directories. I think he is trying to get at a scenario where WRKDIR is on a seperate disk from the one /usr/ports is on. To answer his question, assuming this is what he is going, for why not just add a new physical disk to the system per the handbook, and set WRKDIR to be where ever that disk is mounted. -- WXS ___ 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) ???
I mounted part of RAM as such: mdmfs -s 500m md /mnt Then put WRKDIRPREFIX=/path/to/md in /etc/make.conf. It substantially reduces compile time by about 5-10 times. Thanx to all ur replies. -Ashok Shrestha On 1/19/06, Wesley Shields [EMAIL PROTECTED] wrote: On Thu, Jan 19, 2006 at 05:54:02PM +0100, Dag-Erling Sm?rgrav wrote: Mike Meyer [EMAIL PROTECTED] writes: Will using a swap-backed disk change anything? Not really. How about the best way to configure things to use two disks for the compile? I'm not sure what you are trying to achieve. Unlike the base system, the ports tree does not use separate source and object directories. I think he is trying to get at a scenario where WRKDIR is on a seperate disk from the one /usr/ports is on. To answer his question, assuming this is what he is going, for why not just add a new physical disk to the system per the handbook, and set WRKDIR to be where ever that disk is mounted. -- WXS -- Ashok Shrestha ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Weird PCI interrupt delivery problem (resolution, sort of)
After trying everything I could think of to do to the I/O APIC code and
coming up empty, tonight I went back to the local APIC. I had
previously ruled it out since the lapic timer interrupt continued to
work fine even when the others stopped. However, adding some DELAY(1)
calls at key points caused it to work, much like adding WITNESS does.
I managed to get it down to a single change that makes APIC mode work on
this laptop:
--- local_apic.c.orig Thu Jan 19 18:32:37 2006
+++ local_apic.cThu Jan 19 18:32:28 2006
@@ -599,4 +599,5 @@
lapic_eoi(void)
{
lapic-eoi = 0;
+ lapic-eoi = 0;
}
...and welcome to bizarro world. There's absolutely no reason I can
think of why that would change anything, other than buggy hardware.
I looked at what Linux was doing, and they're also using a single write
to EOI interrupts, so long as the X86_GOOD_APIC config option is enabled
(and it is for P5/MMX or newer). Otherwise it does an extra read before
writing to any APIC register. I don't know if linux works on this
hardware or not -- the live CD I tried wasn't compiled for APIC support.
At this point, since AFAIK nobody else has reported the same problem,
I'm content with a local workaround. It's just... wierd.
Craig
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Weird PCI interrupt delivery problem (resolution, sort of)
Craig Boston wrote:
After trying everything I could think of to do to the I/O APIC code and
coming up empty, tonight I went back to the local APIC. I had
previously ruled it out since the lapic timer interrupt continued to
work fine even when the others stopped. However, adding some DELAY(1)
calls at key points caused it to work, much like adding WITNESS does.
I managed to get it down to a single change that makes APIC mode work on
this laptop:
--- local_apic.c.orig Thu Jan 19 18:32:37 2006
+++ local_apic.cThu Jan 19 18:32:28 2006
@@ -599,4 +599,5 @@
lapic_eoi(void)
{
lapic-eoi = 0;
+ lapic-eoi = 0;
}
...and welcome to bizarro world. There's absolutely no reason I can
think of why that would change anything, other than buggy hardware.
I looked at what Linux was doing, and they're also using a single write
to EOI interrupts, so long as the X86_GOOD_APIC config option is enabled
(and it is for P5/MMX or newer). Otherwise it does an extra read before
writing to any APIC register. I don't know if linux works on this
hardware or not -- the live CD I tried wasn't compiled for APIC support.
At this point, since AFAIK nobody else has reported the same problem,
I'm content with a local workaround. It's just... wierd.
Craig
This points to a bus coherency problem. I wonder if your BIOS is
incorrectly setting the memory region of the apics as cachable. You'll
want to bug Baldwin about this.
Scott
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Newly developed mailling list search engine needs testing
Hi, everybody. Firstly, let me introduce myself. I am Choy Kho Yee, an comp. sci. undergraduate student in Osaka University. For my final year thesis, I have developed a mailing list archive management system called MLwiki. The name MLwiki is made up from the words Mailing List and Wiki. It was developed to overcome some weaknesses of the existing mailing list archiving and searching system and to combine the power of wiki and the huge amount of information in the mailing list archive. With MLwiki, it is hoped that users can get the information they want faster and easier. More information about MLwiki is available on the main page of this system, which is located at MLwiki http://noanoa.ics.es.osaka-u.ac.jp/~k-choy/mlwiki-test/mlwiki.php The questionnaire http://noanoa.ics.es.osaka-u.ac.jp/~k-choy/mlwiki-test/mlwiki_questionaire.html Please read the introduction on the main page before testing the system as it provides some vital information to fully utilize MLwiki. After testing out the system, I would be glad if you can help me out by filling in the questionnaire about this system, which can be accessed through the above address or from MLwiki's main page. Please understand that MLwiki is in its early stage of development and therefore there might be many bugs hidden in it. Bugs reports are welcome. And please remember that this system is still in an experimental stage, all changes you submit might be lost in the future release. But do feel free to test around. This website will be available until 10 February 2006. Accessibility after that will be re-considered depends on the response and the condition of the system. Thanks a lot. --- Choy Kho Yee E-mail: k-choy at ics dot es dot osaka-u dot ac dot jp ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
