Re: harvest_interrupt=YES slows down machine
:This effectively happens. : :The harvest ring is a limited length, and any overflows are discarded. : :M :-- :Mark Murray :Warning: this .sig is umop ap!sdn Are you resending this mail from 5 dats ago or is there a bounce occuring somewhere on the list? Currently the queue size does not limit the interrupt rate due to the way the harvester processes the queue. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
harvest_interrupt=YES slows down machine
Just installed new world, rebuild kernel, ran mergemaster and after reboot discovered that the system slowed down 4-5 times. Turning harvest_interrupt=NO in /etc/rc.conf solved the problem. The system in question is Toshiba Satellite Pro 445 notebook, see dmesg and kernel config attached with this message. Please investigate and fix what is necessary. In the meantime I would suggest turning harvest_interrupt=NO in default rc.conf, as it may hurt others as well. Thanks! -Maxim Copyright (c) 1992-2001 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #2: Tue Mar 6 15:34:23 EET 2001 root@notebook:/usr/src/sys/compile/NOTEBOOK Timecounter "i8254" frequency 1193125 Hz CPU: Pentium/P55C (132.63-MHz 586-class CPU) Origin = "GenuineIntel" Id = 0x543 Stepping = 3 Features=0x8001bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8,MMX real memory = 33685504 (32896K bytes) avail memory = 29618176 (28924K bytes) Preloaded elf kernel "kernel" at 0xc0321000. Preloaded elf module "snd_pcm.ko" at 0xc032109c. Preloaded elf module "snd_mss.ko" at 0xc032113c. Intel Pentium detected, installing workaround for F00F bug WARNING: size of kinfo_proc (648) should be 644!!! VESA: v2.0, 2048k memory, flags:0x0, mode table:0xc02af420 (140) VESA: CHIPS 6x554 Super VGA apm0: APM BIOS on motherboard apm0: found APM BIOS v1.2, connected at v1.2 npx0: math processor on motherboard npx0: INT 16 interface isa0: ISA bus on motherboard ata0 at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 ata1 at port 0x170-0x177,0x376 irq 15 on isa0 atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model GlidePoint, device ID 0 fdc0: NEC 765 or clone at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 pcic0: Intel i82365 at port 0x3e0-0x3e1 on isa0 pcic0: Polling mode pccard0: PC Card bus -- kludge version on pcic0 pccard1: PC Card bus -- kludge version on pcic0 pcm0: OPL3-SA3 (YMF715) at port 0x530-0x537,0x370-0x371 irq 5 drq 1 flags 0xc110 on isa0 pmtimer0 on isa0 ppc0: Parallel port at port 0x378-0x37f irq 7 flags 0x1 on isa0 ppc0: Generic chipset (NIBBLE-only) in NIBBLE mode plip0: PLIP network interface on ppbus0 sc0: System console on isa0 sc0: VGA 16 virtual consoles, flags=0x200 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 unknown: PNP0303 can't assign resources unknown: TOS7400 can't assign resources unknown: PNP0700 can't assign resources unknown: PNP0600 can't assign resources unknown: PNP0600 can't assign resources unknown: PNP0501 can't assign resources unknown: PNP0401 can't assign resources unknown: PNP0e00 can't assign resources unknown: TOS7009 can't assign resources unknown: YMH0021 can't assign resources ad0: 1376MB TOSHIBA MK1403MAV [2796/16/63] at ata0-master BIOSPIO acd0: CDROM TOSHIBA CD-ROM XM-1502BN at ata1-master using BIOSPIO Mounting root from ufs:/dev/ad0s1a pccard: card inserted, slot 0 pccard: card inserted, slot 1 ed0 at port 0x240-0x25f irq 3 slot 0 on pccard0 ed0: address 00:80:c8:88:86:b1, type NE2000 (16 bit) sio1 at port 0x2e8-0x2ef irq 10 slot 1 on pccard1 sio1: type 16550A machine i386 cpu I586_CPU # Coz we don't need stuff for I386, I486 and I686 ident GENERIC maxusers10 #optionsINVARIANTS #options INVARIANT_SUPPORT #options MUTEX_DEBUG #options WITNESS #options WITNESS_DDB #options DDB #optionsKTR #optionsKTR_EXTEND #optionsKTR_COMPILE=KTR_LOCK #optionsKTR_MASK=KTR_LOCK #optionsKTRACE options FFS options NFS options MSDOSFS options INET#InterNETworking options PROCFS #Process filesystem options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options USERCONFIG #boot -c editor options VISUAL_USERCONFIG #visual boot -c editor options NSWAPDEV=1 options CLK_USE_I8254_CALIBRATION options CLK_USE_TSC_CALIBRATION #optionsUSER_LDT options P1003_1B options _KPOSIX_PRIORITY_SCHEDULING options _KPOSIX_VERSION=199309L device random device isa #device pcm device fdc device ata device atadisk device atapicd device atkbdc 1 device atkbd device psm #optionsPSM_HOOKAPM device vga device sc 1 options VESA options SC_PIXEL_MODE #optionsSC_NO_SYSMOUSE options SC_TWOBUTTON_MOUSE options SC_HISTORY_SIZE=1024 device npx device sio device apm device
Re: harvest_interrupt=YES slows down machine
Just installed new world, rebuild kernel, ran mergemaster and after reboot discovered that the system slowed down 4-5 times. Turning harvest_interrupt=NO in /etc/rc.conf solved the problem. The system in question is Toshiba Satellite Pro 445 notebook, see dmesg and kernel config attached with this message. Please investigate and fix what is necessary. In the meantime I would suggest turning harvest_interrupt=NO in default rc.conf, as it may hurt others as well. Apart from a ridiculously low maxusers (you have 10, I recommend 128), I'm not sure what the problem is. Please set maxusers to 128, and time a make world with interrupt harvesting on, and again with it off. M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: harvest_interrupt=YES slows down machine
Apart from a ridiculously low maxusers (you have 10, I recommend 128), I'm not sure what the problem is. I do not see why it is "ridiculously low". Even GENERIC recommends 32, while this is a small system intended to be used by only one person, so I do not see any problem with it. I never had any `out of descriptors' or `can't fork' during my routine operations on this box (2.5 years). Ok - then please leave it at 32. Please set maxusers to 128, and time a make world with interrupt harvesting on, and again with it off. I do not see what it will buy you. Could you please just believe my opinion based on the boot time? After all, even when this box unslowed make world takes 4-5 hours to complete, so with this slowdown it would take about 20-30, which I certainly can't tolerate without sufficient reason. If you want me to help you, please help me get good info. It's very important to me _know_ wether this is a boot slowdown or a generic - assertions are not good enough, I need hard facts. My own laptop (A Toshiba Libretto 110CT) does a make world in about 8 hours (and it always has). Interrupt harvesting has not made a noticable difference (I have not been keeping records, but an overnight build has not yet progressed into my breakfast). M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: harvest_interrupt=YES slows down machine
On Wed, 7 Mar 2001, Mark Murray wrote: Apart from a ridiculously low maxusers (you have 10, I recommend 128), I'm not sure what the problem is. I do not see why it is "ridiculously low". Even GENERIC recommends 32, while this is a small system intended to be used by only one person, so I do not see any problem with it. I never had any `out of descriptors' or `can't fork' during my routine operations on this box (2.5 years). Ok - then please leave it at 32. I use 10 with no problems. If you want me to help you, please help me get good info. It's very important to me _know_ wether this is a boot slowdown or a generic - assertions are not good enough, I need hard facts. My own laptop (A Toshiba Libretto 110CT) does a make world in about 8 hours (and it always has). Interrupt harvesting has not made a noticable difference (I have not been keeping records, but an overnight build has not yet progressed into my breakfast). Just do something that causes a lot of interrupts that go through the random harvester. E.g.: dd if=/dev/ad0 of=/dev/null causes 7750 interrupts/sec here (on a Celeron 366 overclocked to 522). The random task takes 100% of the available cpu cycles. This slows down cpu-bound processes by a factor of about 3.5. With a block size of 64k instead of the default of 512, this causes only 300 interrupts/sec. The random task takes a measly 27% of the cpu to process these. It can apparently only handle about 10 interrupts/second with a reasonable overhead (1%). Interrupt harvesting doesn't make much difference to makeworld because makeworld is cpu-bound. I estimate it to be about 2% here (20 interrupts per second for disk i/o to local disks. It would be a lot more for nfs). Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: harvest_interrupt=YES slows down machine
Just do something that causes a lot of interrupts that go through the random harvester. E.g.: dd if=/dev/ad0 of=/dev/null causes 7750 interrupts/sec here (on a Celeron 366 overclocked to 522). The random task takes 100% of the available cpu cycles. This slows down cpu-bound processes by a factor of about 3.5. With a block size of 64k instead of the default of 512, this causes only 300 interrupts/sec. The random task takes a measly 27% of the cpu to process these. It can apparently only handle about 10 interrupts/second with a reasonable overhead (1%). OK. Try tweaking the "Computational intensity factor" ;-) by dropping the kern.random.yarrow.bins: # sysctl -w kern.random.yarrow.bins=2 And let me know how well that works. M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: harvest_interrupt=YES slows down machine
: causes 7750 interrupts/sec here (on a Celeron 366 overclocked to : 522). The random task takes 100% of the available cpu cycles. This : slows down cpu-bound processes by a factor of about 3.5. With a block : size of 64k instead of the default of 512, this causes only 300 : interrupts/sec. The random task takes a measly 27% of the cpu to : process these. It can apparently only handle about 10 interrupts/second : with a reasonable overhead (1%). : :OK. Try tweaking the "Computational intensity factor" ;-) by dropping :the kern.random.yarrow.bins: : :# sysctl -w kern.random.yarrow.bins=2 : :And let me know how well that works. : :M :-- :Mark Murray I think it would be a much better idea to cap the number of interrupts per second the reseeder accepts. e.g. have a sysctl to set the max and default it to something reasonable, like 200. The seeder would thus only run 200 times a second even if A person were getting 7750 interrupts/sec. Frankly, once we have a good random seed it would only take about 10 interrupts a second to keep the random number generator in good shape, and possibly even less. Overkill is not necessary. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: harvest_interrupt=YES slows down machine
I think it would be a much better idea to cap the number of interrupts per second the reseeder accepts. e.g. have a sysctl to set the max and default it to something reasonable, like 200. The seeder would thus only run 200 times a second even if A person were getting 7750 interrupts/sec. Frankly, once we have a good random seed it would only take about 10 interrupts a second to keep the random number generator in good shape, and possibly even less. Overkill is not necessary. This effectively happens. The harvest ring is a limited length, and any overflows are discarded. M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: harvest_interrupt=YES slows down machine
: I think it would be a much better idea to cap the number of interrupts : per second the reseeder accepts. e.g. have a sysctl to set the : max and default it to something reasonable, like 200. The seeder would : thus only run 200 times a second even if A person were getting : 7750 interrupts/sec. Frankly, once we have a good random seed it would : only take about 10 interrupts a second to keep the random number : generator in good shape, and possibly even less. Overkill is not : necessary. : :This effectively happens. : :The harvest ring is a limited length, and any overflows are discarded. : :M The harvest ring is *HUGE* -- the ring is 1024 entries. Obviously it does not have a problem keeping up with a high interrupt rate. Also, my read of the thread that eats the data off that ring is that the thread pulls everything off the ring in a tight loop, which means that the ring will effectively be empty most of the time no matter how much data gets stuffed into it. So the 'limited length', even a small limited length, does not effectively limit the amount of work being done by the interrupt code. You need to do two things: 1) Reduce the ring size to something reasonable. 1024 is massive overkill. 32 would be just fine. 2) Add a mandatory tsleep in random_kthread() for EACH entry scanned from the harvest ring. Something reasonable like 1/10 second (similar to what you do if the harvest ring is empty. Or may you could pull off 5 entries at a time and then sleep. Right now you run it in a tight loop until the ring is completely empty. A 1/10 second sleep and a ring limit of 32 still gives you an effective 320 seeds per second. Still overkill, but at least not the massive overkill that its doing now. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: harvest_interrupt=YES slows down machine
1) Reduce the ring size to something reasonable. 1024 is massive overkill. 32 would be just fine. I'll play with this. 2) Add a mandatory tsleep in random_kthread() for EACH entry scanned from the harvest ring. Something reasonable like 1/10 second (similar to what you do if the harvest ring is empty. Or may you could pull off 5 entries at a time and then sleep. Right now you run it in a tight loop until the ring is completely empty. Hmm. Sounds doable. I'll play. A 1/10 second sleep and a ring limit of 32 still gives you an effective 320 seeds per second. Still overkill, but at least not the massive overkill that its doing now. Event != seed. I'll juggle numbers and see if I can come up with any tweakables (sysctl's) that could give users more control here. Thanks! M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: harvest_interrupt=YES slows down machine
:Hmm. Sounds doable. I'll play. : : A 1/10 second sleep and a ring limit of 32 still gives you an effective : 320 seeds per second. Still overkill, but at least not the massive : overkill that its doing now. : :Event != seed. I'll juggle numbers and see if I can come up with any :tweakables (sysctl's) that could give users more control here. : :Thanks! : :M :-- :Mark Murray That would be cool, thanks! If the interrupt-based random seed stuff can be made really low profile, I think it will make a great addition to the system. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
