Re: Kern.hz= +1 hertz at anything 2500 and above.
improved with a higher kern.hz rating. Unless the future holds an emu20k2, there will be RAM used from the motherboard. 1. I will need a real-time or a faster kernel- hence the high rate wanted- because the devices to be built will be used in an active environment: art, music, audio control. 2. Any system with limited memory and a low CPU hertz rate benefits from the higher kern.hz setting. rather opposite. more kern.hz=more interrupts. 3. Why not? If it works for PowerPC, SPARC64, AMD64, and i386 then it may work for other architectures. 4. Some applications may be ran from within a jail. On Wed, Jul 24, 2013 at 8:16 PM, Adrian Chadd adr...@freebsd.org wrote: Well, why is it reducing latency? That's the thing you should investigate. Is it because processes aren't getting enough time? or too much time? Or the audio device isn't getting enough time to run? etc. -adrian On 24 July 2013 15:35, Super Bisquit superbisq...@gmail.com wrote: http://lists.freebsd.org/pipermail/freebsd-stable/2009-September/051789.html This is the thread that I was referring to earlier. Since the patch is for 2009, what are the chances it would work with 10.x or 9.x? On PowerPC machines with a low MHz rate- or any machine with a CPU rate of 800 MHz or less- increasing the kern.hz improves performance and cuts down on latency. I am building audio applications and suites that are used in different projects. A G3 based machine should be able to run a kernel with kern.hz=5000 with no problem. Unfortunately, this cannot be done. @PowerPC: some of you may find that performance does increase at a higher kern.hz rate. @Hackers Current: What's the chance that the default rate limit can be raised to 5k? ___ freebsd-...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ppc To unsubscribe, send any mail to freebsd-ppc-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
panic: kmem_map too small at heavy packet traffic
howdy all, At my work, I am using 10.0-CURRENT on Intel(R) Xeon(R) E5620 with 16GB ram. I am taking panic: kmem_malloc(-548663296): kmem_map too small: 539459584 total allocated message with configuration below: [root@ ~]# sysctl vm.kmem_size_min vm.kmem_size_max vm.kmem_size vm.kmem_size_scale vm.kmem_size_min: 0 vm.kmem_size_max: 329853485875 vm.kmem_size: 16686845952 vm.kmem_size_scale: 1 [root@ ~]# sysctl hw.physmem hw.usermem hw.realmem hw.physmem: 17151787008 hw.usermem: 8282652672 hw.realmem: 18253611008 [root@ ~]# sysctl hw.pagesize hw.pagesizes hw.availpages hw.pagesize: 4096 hw.pagesizes: 4096 2097152 0 hw.availpages: 4187448 When I compare vmstat and netstat output of boot time result and subsequent result, the major difference are seemed at: pf_temp 0 0K - 79309736 128 | pf_temp 1077640 134705K - 84330076 128 and after the panic at the core dump file the major vmstat difference is: temp 110 15K - 76212305 16,32,64,128,256 | temp 117 6742215K - 655115 16,32,64,128,2 When I explore the source code of kernel (at vm_kern.c and vm_map.c), I see that the panic can occur with the cases at below: * negative malloc size parameter * longer than free buffer respect to kmem_map min_offset and max_offset values * try to allocate when the root entry of map is the rightmost entry of map * try to allocate bigger than map's max_free value I think the panic occurs at mbuf creation process when calling malloc() as a result of couldn't be able to allocate memory; but I don't understand why one of this panic case activating? The memory is almost empty but the device is saying kmem_map small when using about 0.5GB memory purely. How can i solve this panic problem? Thank you all for your time. -- Best Wishes, Tugrul Erdogan ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Kern.hz= +1 hertz at anything 2500 and above.
On 25 July 2013 02:51, Wojciech Puchar woj...@wojtek.tensor.gdynia.pl wrote: improved with a higher kern.hz rating. Unless the future holds an emu20k2, there will be RAM used from the motherboard. 1. I will need a real-time or a faster kernel- hence the high rate wanted- because the devices to be built will be used in an active environment: art, music, audio control. 2. Any system with limited memory and a low CPU hertz rate benefits from the higher kern.hz setting. rather opposite. more kern.hz=more interrupts. Right. More hz == more interrupts and less ability for a CPU-bound process to chew all the CPU. So is it a scheduling issue, where you have multiple CPU bound userland processes that aren't being fair and consuming all the CPU? Is it that your device driver(s) aren't interrupting correctly, relying on the hz tick to make up the slack, etc. Is it a busted halt loop, which is being papered over with hz ticks? Have you tried -10 on that kit, with the more aggressive clock/timer code that won't interrupt unless it needs to? Has that changed things? -adrian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Kern.hz= +1 hertz at anything 2500 and above.
I haven't done much messing with scheduling. It is set at the default ULE for this machine. On Thu, Jul 25, 2013 at 12:11 PM, Adrian Chadd adr...@freebsd.org wrote: On 25 July 2013 02:51, Wojciech Puchar woj...@wojtek.tensor.gdynia.pl wrote: improved with a higher kern.hz rating. Unless the future holds an emu20k2, there will be RAM used from the motherboard. 1. I will need a real-time or a faster kernel- hence the high rate wanted- because the devices to be built will be used in an active environment: art, music, audio control. 2. Any system with limited memory and a low CPU hertz rate benefits from the higher kern.hz setting. rather opposite. more kern.hz=more interrupts. Right. More hz == more interrupts and less ability for a CPU-bound process to chew all the CPU. So is it a scheduling issue, where you have multiple CPU bound userland processes that aren't being fair and consuming all the CPU? Is it that your device driver(s) aren't interrupting correctly, relying on the hz tick to make up the slack, etc. Is it a busted halt loop, which is being papered over with hz ticks? Have you tried -10 on that kit, with the more aggressive clock/timer code that won't interrupt unless it needs to? Has that changed things? -adrian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
