Re: boot loader
> You also can't dual boot without console access. You can, I have a system triple booting without using the console. Method 1: boot through grub. Create shell scripts that edit grub's menu.lst file. Method 2: use fdisk(8) to change active partition. With or without dual booting, if the least little thing goes wrong you will need the console, and maybe the reset button, and maybe the hard power switch to recover. Even rebooting without changing anything can be dangerous since fsck might decide to be unhappy. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: amrd disk performance drop after running under high load
Hi Kris Kennaway wrote: So I can conclude that FreeBSD has a long standing bug in VM that could be triggered when serving large amount of static data (much bigger than memory size) on high rates. Possibly this only applies to large files like mp3 or video. It is possible, we have further work to do to conclude this though. I forgot to mention I have pmc and kgmon profiling for good and bad times. But I have not enough knowledge to interpret it right and not sure if it can help. pmc would be useful. pmc profiling attached. OK, the pmc traces do seem to show that it's not a lock contention issue. That being the case I don't think the fact that different servers perform better is directly related. But it was evidence of mbuf lock contention in mutex profiling, wasn't it? As far as I understand, mutex problems can exist without increasing CPU load in pmc stats, right? There is also no evidence of a VM problem. What your vmstat and pmc traces show is that your system really isn't doing much work at all, relatively speaking. There is also still no evidence of a disk problem. In fact your disk seems to be almost idle in both cases you provided, only doing between 1 and 10 operations per second, which is trivial. vmstat and network output graphs shows that the problem exists. If it is not a disk or network or VM problem, what else could be wrong? In the "good" case you are getting a much higher interrupt rate but with the data you provided I can't tell where from. You need to run vmstat -i at regular intervals (e.g. every 10 seconds for a minute) during the "good" and "bad" times, since it only provides counters and an average rate over the uptime of the system. I'll try this, but AFAIR there was no strangeness with interrupts. I believe the reason of high interrupt rate in "good" cases is that server sends much traffic. What there is evidence of is an interrupt aliasing problem between em and USB: irq16: uhci0 1464547796 1870 irq64: em01463513610 1869 I tried disabling USB in kernel, this ussie was gone, but the main problem was left. Also I have this issue with interrupt aliasing on many servers without problems. With best regards, Alexey Popov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ``Stopping RAM access''
>> Can anyone give me a clue, how one can ``stop'' system from accessing RAM, and then allow it again? > > I think this has no aim, RAM tests should be done during booting, but > u could try to disable interrupts while in kernel mode 'cli' which > will prevent any further context switching, then try to do whatever > you want, finally enable interrupts back 'sti'. > > That's my two cents. I don't whether it will work or not. > Also, keep in mind that 'cli/sti' is just a starting point. You can't just go playing with memory anywhere you want because interrupts are disabled. What if a DMA transfer is in progress? Mike ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: ``Stopping RAM access''
Well, if the system stops accessing RAM, you had better make sure that *all* the instructions you need are already loaded into the L1 and L2 caches. Otherwise you won't be able to turn RAM back on. That would involve carefully preloading everything through use of the system's appropriate PREFETCH calls, locking down the cache lines to make sure nothing else disturbs them, turning off interrupts, and probably more. To actually turn off RAM, you'd have to power down or otherwise disable the memory controller interface on your board. The procedures for that would be highly platform dependent. /Andrew > -Original Message- > From: [EMAIL PROTECTED] [mailto:owner-freebsd- > [EMAIL PROTECTED] On Behalf Of Maslan > Sent: Tuesday, October 30, 2007 5:02 PM > To: Jaroszewski Łukasz > Cc: freebsd-hackers@freebsd.org > Subject: Re: ``Stopping RAM access'' > > > Can anyone give me a clue, how one can ``stop'' system from accessing > > RAM, and then allow it again? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: amrd disk performance drop after running under high load
Alexey Popov wrote: Hi Kris Kennaway wrote: So I can conclude that FreeBSD has a long standing bug in VM that could be triggered when serving large amount of static data (much bigger than memory size) on high rates. Possibly this only applies to large files like mp3 or video. It is possible, we have further work to do to conclude this though. I forgot to mention I have pmc and kgmon profiling for good and bad times. But I have not enough knowledge to interpret it right and not sure if it can help. pmc would be useful. pmc profiling attached. OK, the pmc traces do seem to show that it's not a lock contention issue. That being the case I don't think the fact that different servers perform better is directly related. But it was evidence of mbuf lock contention in mutex profiling, wasn't it? As far as I understand, mutex problems can exist without increasing CPU load in pmc stats, right? No, the lock functions will show up as using a lot of CPU. I guess the lock profiling trace showed high numbers because you ran it for a long time. There is also no evidence of a VM problem. What your vmstat and pmc traces show is that your system really isn't doing much work at all, relatively speaking. There is also still no evidence of a disk problem. In fact your disk seems to be almost idle in both cases you provided, only doing between 1 and 10 operations per second, which is trivial. vmstat and network output graphs shows that the problem exists. If it is not a disk or network or VM problem, what else could be wrong? The vmstat output you provided so far doesn't show anything specific. In the "good" case you are getting a much higher interrupt rate but with the data you provided I can't tell where from. You need to run vmstat -i at regular intervals (e.g. every 10 seconds for a minute) during the "good" and "bad" times, since it only provides counters and an average rate over the uptime of the system. I'll try this, but AFAIR there was no strangeness with interrupts. I believe the reason of high interrupt rate in "good" cases is that server sends much traffic. What there is evidence of is an interrupt aliasing problem between em and USB: irq16: uhci0 1464547796 1870 irq64: em01463513610 1869 I tried disabling USB in kernel, this ussie was gone, but the main problem was left. Also I have this issue with interrupt aliasing on many servers without problems. OK. Kris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
floating point operations
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 hackers, We've been making experimental changes to FreeBSD's TCP congestion control code, and we used a few floating point operations initially in our prototype. We've since gone back and converted all but one of the operations to fixed point maths in following the no-flops-in-kernel mantra. The remaining op is not easily converted to fixed point math, and we're wondering what impact a single flop on the receipt of each ACK will have. We don't have a strong understanding of the amount of overhead involved in executing a flop instead of an int op on modern hardware. regards James Healy -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHKRJU4oawkrbYo/kRAnhtAJwJOzBh9LhT3cQkRp6hYze2w44pcgCfSbLj irZWz4qHd6lw0zjVaH/6d3s= =3eLF -END PGP SIGNATURE- Swinburne University of Technology CRICOS Provider Code: 00111D NOTICE This e-mail and any attachments are confidential and intended only for the use of the addressee. They may contain information that is privileged or protected by copyright. If you are not the intended recipient, any dissemination, distribution, printing, copying or use is strictly prohibited. The University does not warrant that this e-mail and any attachments are secure and there is also a risk that it may be corrupted in transmission. It is your responsibility to check any attachments for viruses or defects before opening them. If you have received this transmission in error, please contact us on +61 3 9214 8000 and delete it immediately from your system. We do not accept liability in connection with computer virus, data corruption, delay, interruption, unauthorised access or unauthorised amendment. Please consider the environment before printing this email. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
memory pool, rfc
Hello: I have some free time and want to do an memory pool. The idea is to have a memory zone of N KB (or several MB) compressed in memory. I have fast compression algorithms now that can release under BSD licence that are faster than hd i/o, so it take less compress/decompress a memory zone than read/write it to disk. I don't know if it already exist for FreeBSD, so if it's already done i'll try to improve it. - Each memory chunk is compressed separately, so i can decompress and use one without decompress anyother one. - In 4KB chunks of text i get 50-60 % compression (avg 2 - 1.6 KB result) - In 4KB chunks of binary (application code) i get 30-40 % compression (avg 2.8 - 2.4 KB result) - In both cases, results may vary depending on data type and chunk size, greater implies better compression - Speed once implemented will be very fast. Current speed hogs a PATA 133 disk. For what can be used? - Memory pools in applications (like malloc) - Ram disks - Disk Cache (permit bigger disk cache) - 'On the fly' filesystem compression (and it takes less read/write compressed data than non-compressed) - Perhaps add it as Virtual Memory swap cache? - Other Don't point me to zlib or libbzip2, they are on another league and are much slower than my code. Thanks ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: memory pool, rfc
In the last episode (Nov 01), Eduardo Morras said: > I have some free time and want to do an memory pool. The idea is to > have a memory zone of N KB (or several MB) compressed in memory. I > have fast compression algorithms now that can release under BSD > licence that are faster than hd i/o, so it take less > compress/decompress a memory zone than read/write it to disk. I don't > know if it already exist for FreeBSD, so if it's already done i'll > try to improve it. [...] > For what can be used? > > - Memory pools in applications (like malloc) > - Ram disks > - Disk Cache (permit bigger disk cache) > - 'On the fly' filesystem compression (and it takes less read/write > compressed data than non-compressed) zfs already has modular compression algorithms; it would be rather easy to add a mozule for your method and compare it to the existing gzip and lzjb algorithms. -- Dan Nelson [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
