tag:old.nabble.com,2006:forum-20227 2009-12-14T18:02:19Z Discussion for the kernel of the DragonFly BSD Operating System. <br><br>DragonFly is an operating system and environment originally based on FreeBSD. It belongs to the same class of operating system as BSD and Linux and is based on the same UNIX ideals and APIs. tag:old.nabble.com,2006:post-26788337 2009-12-14T18:02:19Z 2009-12-14T18:02:19Z Petr Janda-2 Im running i386/master and even during minimal usage i get over 1GB of <br>active memory. <br><br>top: <br><br>Memory: 1081M Active, 1368M Inact, 378M Wired, 35M Cache, 143M Buf, 644M Free <br>Swap: 4096M Total, 77M Used, 4019M Free, 1% Inuse <br><br><br>ps -aux <br><br>root &nbsp; &nbsp; &nbsp;6576 &nbsp;1.5 &nbsp;0.0 &nbsp;3984 &nbsp;972 &nbsp; 1 &nbsp;SLM &nbsp;10:08AM &nbsp; 0:00.29 _su (csh) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BLM &nbsp;11:16PM &nbsp; 0:10.64 <br>(tcp_thread 1) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BLM &nbsp;11:16PM &nbsp; 0:00.01 <br>(udp_thread 1) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BLM &nbsp;11:16PM &nbsp; 0:00.00 <br>(taskq_cpu 1) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BLM &nbsp;11:16PM &nbsp; 0:00.00 &nbsp;(ifnet 1) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BLM &nbsp;11:16PM &nbsp; 0:00.00 <br>(netisr_cpu 1) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BLM &nbsp;11:16PM &nbsp; 0:00.09 &nbsp;(usched 1) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BL &nbsp; 11:16PM &nbsp; 0:00.00 &nbsp;(dsched 1) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BL &nbsp; 11:16PM &nbsp; 0:00.44 <br>(softclock 1) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BLM &nbsp;11:16PM 818:55.34 &nbsp;(idle_1) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BL &nbsp; 11:16PM &nbsp; 0:00.00 &nbsp;(vnlru) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BL &nbsp; 11:16PM &nbsp; 0:52.53 &nbsp;(syncer) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BL &nbsp; 11:16PM &nbsp; 0:00.00 <br>(bufdaemon_hw) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BL &nbsp; 11:16PM &nbsp; 0:00.00 &nbsp;(bufdaemon) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BL &nbsp; 11:16PM &nbsp; 0:00.00 &nbsp;(vmdaemon) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BL &nbsp; 11:16PM &nbsp; 0:08.24 &nbsp;(pagedaemon) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BL &nbsp; 11:16PM &nbsp; 0:06.86 &nbsp;(hammer-S3) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BL &nbsp; 11:16PM &nbsp; 0:06.82 &nbsp;(hammer-S2) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BL &nbsp; 11:16PM &nbsp; 0:06.82 &nbsp;(hammer-S1) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BL &nbsp; 11:16PM &nbsp; 0:06.72 &nbsp;(hammer-S0) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BL &nbsp; 11:16PM &nbsp; 0:09.15 &nbsp;(hammer-M) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BL &nbsp; 11:16PM &nbsp; 0:00.02 <br>(rtable_cpu 0) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BLM &nbsp;11:16PM &nbsp; 0:01.59 <br>(tcp_thread 0) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BLM &nbsp;11:16PM &nbsp; 0:00.35 <br>(udp_thread 0) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BL &nbsp; 11:16PM &nbsp; 0:01.23 &nbsp;(random) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BLM &nbsp;11:16PM &nbsp; 0:00.00 &nbsp;(ithread 12) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BLM &nbsp;11:16PM &nbsp; 0:00.00 &nbsp;(ithread 1) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BL &nbsp; 11:16PM &nbsp; 0:00.50 &nbsp;(usb5) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BLM &nbsp;11:16PM &nbsp; 0:00.00 &nbsp;(ithread 10) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BL &nbsp; 11:16PM &nbsp; 0:00.50 &nbsp;(usb4) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BL &nbsp; 11:16PM &nbsp; 0:00.50 &nbsp;(usb3) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BL &nbsp; 11:16PM &nbsp; 0:00.00 &nbsp;(ithread 14) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BLM &nbsp;11:16PM &nbsp; 0:15.98 &nbsp;(ithread 11) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BL &nbsp; 11:16PM &nbsp; 0:00.50 &nbsp;(usb2) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BL &nbsp; 11:16PM &nbsp; 0:00.00 &nbsp;(ithread 7) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BL &nbsp; 11:16PM &nbsp; 0:00.50 &nbsp;(usb1) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BLM &nbsp;11:16PM &nbsp; 0:00.00 &nbsp;(ithread 5) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BL &nbsp; 11:16PM &nbsp; 0:00.00 &nbsp;(usbtask-dr) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BL &nbsp; 11:16PM &nbsp; 0:00.00 &nbsp;(usbtask-hc) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BL &nbsp; 11:16PM &nbsp; 0:00.50 &nbsp;(usb0) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BL &nbsp; 11:16PM &nbsp; 0:00.00 <br>(ciss_notify0) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BL &nbsp; 11:16PM &nbsp; 0:16.94 &nbsp;(ithread 2) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BLM &nbsp;11:16PM &nbsp; 0:00.00 &nbsp;(ithread 4) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BLM &nbsp;11:16PM &nbsp; 0:00.00 &nbsp;(ithread 64) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BLM &nbsp;11:16PM &nbsp; 0:00.00 &nbsp;(ithread 9) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BL &nbsp; 11:16PM &nbsp; 0:00.00 &nbsp;(acpi_task) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BL &nbsp; 11:16PM &nbsp; 0:00.00 &nbsp;(ithread 69) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BL &nbsp; 11:16PM &nbsp; 0:07.23 &nbsp;(ithread 67) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BL &nbsp; 11:16PM &nbsp; 0:00.00 &nbsp;(xpt_thrd) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BL &nbsp; 11:16PM &nbsp; 0:00.00 &nbsp;(crypto <br>returns) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BL &nbsp; 11:16PM &nbsp; 0:00.00 &nbsp;(crypto) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BLM &nbsp;11:16PM &nbsp; 0:00.00 <br>(taskq_cpu 0) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BLM &nbsp;11:16PM &nbsp; 0:00.10 &nbsp;(ifnet 0) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BL &nbsp; 11:16PM &nbsp; 0:00.01 <br>(devfs_msg_core) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BL &nbsp; 11:16PM &nbsp; 0:00.00 <br>(disk_msg_core) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BLM &nbsp;11:16PM &nbsp; 0:00.41 <br>(netisr_cpu 0) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BLM &nbsp;11:16PM &nbsp; 0:00.12 &nbsp;(usched 0) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BL &nbsp; 11:16PM &nbsp; 0:00.00 &nbsp;(dsched 0) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BLM &nbsp;11:16PM &nbsp; 0:00.00 &nbsp;(ithread 68) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BL &nbsp; 11:16PM &nbsp; 8:14.51 <br>(softclock 0) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BLM &nbsp;11:16PM &nbsp; 0:00.00 &nbsp;(ithread 0) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BL &nbsp; 11:16PM &nbsp; 0:00.00 &nbsp;(ithread <br>emerg) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BLM &nbsp;11:16PM 809:06.45 &nbsp;(idle_0) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BL &nbsp; 11:16PM &nbsp; 0:00.02 <br>(rtable_cpu 3) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BLM &nbsp;11:16PM &nbsp; 0:06.54 <br>(tcp_thread 3) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BLM &nbsp;11:16PM &nbsp; 0:00.02 <br>(udp_thread 3) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BLM &nbsp;11:16PM &nbsp; 0:00.00 <br>(taskq_cpu 3) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BLM &nbsp;11:16PM &nbsp; 0:00.00 &nbsp;(ifnet 3) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BLM &nbsp;11:16PM &nbsp; 0:00.00 <br>(netisr_cpu 3) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BLM &nbsp;11:16PM &nbsp; 0:00.09 &nbsp;(usched 3) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BL &nbsp; 11:16PM &nbsp; 0:00.00 &nbsp;(dsched 3) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BL &nbsp; 11:16PM &nbsp; 0:00.81 <br>(softclock 3) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BLM &nbsp;11:16PM 819:15.67 &nbsp;(idle_3) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BL &nbsp; 11:16PM &nbsp; 0:00.02 <br>(rtable_cpu 2) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BLM &nbsp;11:16PM &nbsp; 0:02.49 <br>(tcp_thread 2) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BLM &nbsp;11:16PM &nbsp; 0:00.00 <br>(udp_thread 2) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BLM &nbsp;11:16PM &nbsp; 0:00.00 <br>(taskq_cpu 2) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BLM &nbsp;11:16PM &nbsp; 0:00.00 &nbsp;(ifnet 2) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BLM &nbsp;11:16PM &nbsp; 0:00.00 <br>(netisr_cpu 2) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BLM &nbsp;11:16PM &nbsp; 0:00.12 &nbsp;(usched 2) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BL &nbsp; 11:16PM &nbsp; 0:00.00 &nbsp;(dsched 2) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BL &nbsp; 11:16PM &nbsp; 0:00.68 <br>(softclock 2) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BLM &nbsp;11:16PM 817:55.21 &nbsp;(idle_2) <br>root &nbsp; &nbsp; &nbsp; &nbsp; 0 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;DLs &nbsp;10:16AM &nbsp; 0:10.67 &nbsp;(swapper) <br>root &nbsp; &nbsp; &nbsp; &nbsp; 1 &nbsp;0.0 &nbsp;0.0 &nbsp;1428 &nbsp; 88 &nbsp;?? &nbsp;ILs &nbsp;10:16AM &nbsp; 0:00.17 /sbin/init -- <br>root &nbsp; &nbsp; &nbsp; 102 &nbsp;0.0 &nbsp;0.0 &nbsp; 304 &nbsp; &nbsp;4 &nbsp;?? &nbsp;ILMs 10:16AM &nbsp; 0:00.00 adjkerntz -i <br>root &nbsp; &nbsp; &nbsp; 328 &nbsp;0.0 &nbsp;0.0 &nbsp;1756 &nbsp;560 &nbsp;?? &nbsp;SLs &nbsp;11:16PM &nbsp; 0:00.10 <br>/usr/sbin/syslogd -ss <br>root &nbsp; &nbsp; &nbsp; 538 &nbsp;0.0 &nbsp;0.0 &nbsp;2276 &nbsp;524 &nbsp;?? &nbsp;SLMs 11:16PM &nbsp; 0:00.41 <br>/usr/sbin/dntpd <br>root &nbsp; &nbsp; &nbsp; 623 &nbsp;0.0 &nbsp;0.0 &nbsp;4984 &nbsp;744 &nbsp;?? &nbsp;ILs &nbsp;11:16PM &nbsp; 0:00.26 <br>/usr/sbin/sshd <br>root &nbsp; &nbsp; &nbsp; 637 &nbsp;0.0 &nbsp;0.0 &nbsp;5484 &nbsp;884 &nbsp;?? &nbsp;SLs &nbsp;11:16PM &nbsp; 0:00.57 sendmail: <br>accepting connections (sendmail) <br>smmsp &nbsp; &nbsp; &nbsp;641 &nbsp;0.0 &nbsp;0.0 &nbsp;5356 &nbsp;832 &nbsp;?? &nbsp;ILMs 11:16PM &nbsp; 0:00.01 sendmail: <br>Queue runner@00:30:00 for /var/spool/clientmqueue (sendmail) <br>root &nbsp; &nbsp; &nbsp; 656 &nbsp;0.0 &nbsp;0.0 &nbsp;2620 &nbsp;732 &nbsp;?? &nbsp;ILMs 11:16PM &nbsp; 0:00.04 <br>/usr/sbin/cron <br>pgsql &nbsp; &nbsp; &nbsp;679 &nbsp;0.0 &nbsp;0.1 852176 2180 con- IL &nbsp; 11:16PM &nbsp; 0:00.56 <br>/usr/pkg/bin/postgres -D /usr/pkg/pgsql/data <br>pgsql &nbsp; &nbsp; &nbsp;681 &nbsp;0.0 &nbsp;0.1 852752 1988 &nbsp;?? &nbsp;SLs &nbsp;11:16PM &nbsp; 0:04.99 postgres: <br>writer process &nbsp; &nbsp;(postgres) <br>pgsql &nbsp; &nbsp; &nbsp;682 &nbsp;0.0 &nbsp;0.0 852560 1300 &nbsp;?? &nbsp;SLs &nbsp;11:16PM &nbsp; 0:03.94 postgres: <br>wal writer process &nbsp; &nbsp;(postgres) <br>pgsql &nbsp; &nbsp; &nbsp;683 &nbsp;0.0 &nbsp;0.0 852784 1604 &nbsp;?? &nbsp;SLs &nbsp;11:16PM &nbsp; 0:01.54 postgres: <br>autovacuum launcher process &nbsp; &nbsp;(postgres) <br>pgsql &nbsp; &nbsp; &nbsp;684 &nbsp;0.0 &nbsp;0.0 &nbsp;8472 1144 &nbsp;?? &nbsp;SLMs 11:16PM &nbsp; 0:02.01 postgres: <br>stats collector process &nbsp; &nbsp;(postgres) <br>root &nbsp; &nbsp; &nbsp; 735 &nbsp;0.0 &nbsp;0.0 &nbsp;1804 &nbsp;444 &nbsp;v0 &nbsp;ILs+ 11:16PM &nbsp; 0:00.01 <br>/usr/libexec/getty Pc ttyv0 <br>root &nbsp; &nbsp; &nbsp; 736 &nbsp;0.0 &nbsp;0.0 &nbsp;1804 &nbsp;444 &nbsp;v1 &nbsp;ILs+ 11:16PM &nbsp; 0:00.00 <br>/usr/libexec/getty Pc ttyv1 <br>root &nbsp; &nbsp; &nbsp; 737 &nbsp;0.0 &nbsp;0.0 &nbsp;1804 &nbsp;444 &nbsp;v2 &nbsp;ILs+ 11:16PM &nbsp; 0:00.00 <br>/usr/libexec/getty Pc ttyv2 <br>root &nbsp; &nbsp; &nbsp; 738 &nbsp;0.0 &nbsp;0.0 &nbsp;1804 &nbsp;444 &nbsp;v3 &nbsp;ILs+ 11:16PM &nbsp; 0:00.01 <br>/usr/libexec/getty Pc ttyv3 <br>root &nbsp; &nbsp; &nbsp; 739 &nbsp;0.0 &nbsp;0.0 &nbsp;1804 &nbsp;444 &nbsp;v4 &nbsp;ILs+ 11:16PM &nbsp; 0:00.01 <br>/usr/libexec/getty Pc ttyv4 <br>root &nbsp; &nbsp; &nbsp; 740 &nbsp;0.0 &nbsp;0.0 &nbsp;1804 &nbsp;444 &nbsp;v5 &nbsp;ILs+ 11:16PM &nbsp; 0:00.00 <br>/usr/libexec/getty Pc ttyv5 <br>root &nbsp; &nbsp; &nbsp; 741 &nbsp;0.0 &nbsp;0.0 &nbsp;1804 &nbsp;444 &nbsp;v6 &nbsp;ILs+ 11:16PM &nbsp; 0:00.01 <br>/usr/libexec/getty Pc ttyv6 <br>root &nbsp; &nbsp; &nbsp; 742 &nbsp;0.0 &nbsp;0.0 &nbsp;1804 &nbsp;444 &nbsp;v7 &nbsp;ILs+ 11:16PM &nbsp; 0:00.00 <br>/usr/libexec/getty Pc ttyv7 <br>root &nbsp; &nbsp; &nbsp;6568 &nbsp;0.0 &nbsp;0.0 &nbsp;7928 &nbsp;880 &nbsp;?? &nbsp;ILs &nbsp;10:08AM &nbsp; 0:00.04 sshd: <br>sysadmin [priv] (sshd) <br>sysadmin &nbsp;6570 &nbsp;0.0 &nbsp;0.0 &nbsp;7896 &nbsp;956 &nbsp;?? &nbsp;SL &nbsp; 10:08AM &nbsp; 0:01.92 sshd: <br>sysadmin@pts/1 (sshd) <br>sysadmin &nbsp;6571 &nbsp;0.0 &nbsp;0.0 &nbsp;3612 &nbsp;108 &nbsp; 1 &nbsp;ILMs 10:08AM &nbsp; 0:00.01 -tcsh (tcsh) <br>root &nbsp; &nbsp; &nbsp;6575 &nbsp;0.0 &nbsp;0.0 &nbsp;2904 &nbsp;580 &nbsp; 1 &nbsp;IL &nbsp; 10:08AM &nbsp; 0:00.01 su <br>root &nbsp; &nbsp; 54801 &nbsp;0.0 &nbsp;0.1 &nbsp;7928 2404 &nbsp;?? &nbsp;ILs &nbsp;12:27PM &nbsp; 0:00.05 sshd: <br>sysadmin [priv] (sshd) <br>sysadmin 54803 &nbsp;0.0 &nbsp;0.1 &nbsp;7800 1880 &nbsp;?? &nbsp;IL &nbsp; 12:27PM &nbsp; 0:00.10 sshd: <br>sysadmin@pts/0 (sshd) <br>sysadmin 54804 &nbsp;0.0 &nbsp;0.0 &nbsp;3612 1252 &nbsp; 0 &nbsp;ILMs 12:27PM &nbsp; 0:00.03 -tcsh (tcsh) <br>root &nbsp; &nbsp; 54808 &nbsp;0.0 &nbsp;0.0 &nbsp;2904 1264 &nbsp; 0 &nbsp;IL &nbsp; 12:27PM &nbsp; 0:00.01 su <br>root &nbsp; &nbsp; 54809 &nbsp;0.0 &nbsp;0.0 &nbsp;3904 1308 &nbsp; 0 &nbsp;IL+ &nbsp;12:28PM &nbsp; 0:00.09 _su (csh) <br>root &nbsp; &nbsp; 55111 &nbsp;0.0 &nbsp;0.1 &nbsp;7880 3572 &nbsp;?? &nbsp;SLs &nbsp;12:36PM &nbsp; 0:00.11 <br>/usr/pkg/sbin/httpd -k start <br>www &nbsp; &nbsp; &nbsp;55113 &nbsp;0.0 &nbsp;0.1 &nbsp;7800 1892 &nbsp;?? &nbsp;SL &nbsp; 12:36PM &nbsp; 0:00.00 <br>/usr/pkg/sbin/httpd -k start <br>www &nbsp; &nbsp; &nbsp;55114 &nbsp;0.0 &nbsp;0.1 &nbsp;7880 2084 &nbsp;?? &nbsp;IL &nbsp; 12:36PM &nbsp; 0:00.00 <br>/usr/pkg/sbin/httpd -k start <br>www &nbsp; &nbsp; &nbsp;55115 &nbsp;0.0 &nbsp;0.1 &nbsp;7880 2088 &nbsp;?? &nbsp;SL &nbsp; 12:36PM &nbsp; 0:00.01 <br>/usr/pkg/sbin/httpd -k start <br>www &nbsp; &nbsp; &nbsp;55116 &nbsp;0.0 &nbsp;0.1 &nbsp;7880 2084 &nbsp;?? &nbsp;IL &nbsp; 12:36PM &nbsp; 0:00.00 <br>/usr/pkg/sbin/httpd -k start <br>www &nbsp; &nbsp; &nbsp;55117 &nbsp;0.0 &nbsp;0.1 &nbsp;7880 2084 &nbsp;?? &nbsp;IL &nbsp; 12:36PM &nbsp; 0:00.01 <br>/usr/pkg/sbin/httpd -k start <br>www &nbsp; &nbsp; &nbsp;55118 &nbsp;0.0 &nbsp;0.1 &nbsp;7880 2084 &nbsp;?? &nbsp;IL &nbsp; 12:36PM &nbsp; 0:00.00 <br>/usr/pkg/sbin/httpd -k start <br>root &nbsp; &nbsp; 55220 &nbsp;0.0 &nbsp;0.0 &nbsp;2864 1004 &nbsp;?? &nbsp;SLMs 12:47PM &nbsp; 0:00.01 <br>/usr/sbin/rpcbind <br>root &nbsp; &nbsp; 55365 &nbsp;0.0 &nbsp;0.0 &nbsp;2268 &nbsp;708 &nbsp;?? &nbsp;ILs &nbsp;12:51PM &nbsp; 0:00.00 <br>/sbin/mountd -r <br>pgsql &nbsp; &nbsp;55370 &nbsp;0.0 &nbsp;0.1 853512 4144 &nbsp;?? &nbsp;ILs &nbsp;12:52PM &nbsp; 0:00.00 postgres: <br>aubill xxxx_production xxx.xx.xxx.xxx(57026) idle (postgres) <br>pgsql &nbsp; &nbsp;55372 &nbsp;0.0 &nbsp;0.1 853448 4148 &nbsp;?? &nbsp;ILs &nbsp;12:52PM &nbsp; 0:00.00 postgres: <br>aubill xxx_production xxx.xxx.xx.xxx(51220) idle (postgres) <br>root &nbsp; &nbsp; 55445 &nbsp;0.0 &nbsp;0.0 &nbsp;1720 &nbsp;476 &nbsp;?? &nbsp;ILs &nbsp;12:55PM &nbsp; 0:00.02 nfsd: <br>master (nfsd) <br>root &nbsp; &nbsp; 55446 &nbsp;0.0 &nbsp;0.0 &nbsp; 928 &nbsp;276 &nbsp;?? &nbsp;IL &nbsp; 12:55PM &nbsp; 0:00.00 nfsd: <br>server (nfsd) <br>root &nbsp; &nbsp; 55447 &nbsp;0.0 &nbsp;0.0 &nbsp; 928 &nbsp;276 &nbsp;?? &nbsp;IL &nbsp; 12:55PM &nbsp; 0:00.00 nfsd: <br>server (nfsd) <br>root &nbsp; &nbsp; 55448 &nbsp;0.0 &nbsp;0.0 &nbsp; 928 &nbsp;276 &nbsp;?? &nbsp;IL &nbsp; 12:55PM &nbsp; 0:00.00 nfsd: <br>server (nfsd) <br>root &nbsp; &nbsp; 55449 &nbsp;0.0 &nbsp;0.0 &nbsp; 928 &nbsp;276 &nbsp;?? &nbsp;IL &nbsp; 12:55PM &nbsp; 0:00.00 nfsd: <br>server (nfsd) <br>root &nbsp; &nbsp; &nbsp; &nbsp;-1 &nbsp;0.0 &nbsp;0.0 &nbsp; &nbsp; 0 &nbsp; &nbsp;0 &nbsp;?? &nbsp;BL &nbsp; 11:16PM &nbsp; 0:00.02 <br>(rtable_cpu 1) <br>root &nbsp; &nbsp; 55475 &nbsp;0.0 &nbsp;0.0 &nbsp;1060 &nbsp;560 &nbsp; 1 &nbsp;R1L+ &nbsp;1:00PM &nbsp; 0:00.00 ps -aux <br><br>I firstly noticed a massive spike in memory usage on a fresh install after <br>running &quot;hammer cleanup&quot;. It went to like 1.5GB <br><br>Any ideas? <br><br><br> tag:old.nabble.com,2006:post-26771837 2009-12-13T17:19:03Z 2009-12-13T17:19:03Z Matthew Dillon <br>:I've got the wrapper script I use for building and uploading all of pkgsrc <br>:on DragonFly cleaned up, and I put together a web page for it: <br>: <br>:<a href="http://www.shiningsilence.com/simplepbulk/" target="_top" rel="nofollow">http://www.shiningsilence.com/simplepbulk/</a><br>: <br>:It's a few shell scripts, so it's easy to look at. &nbsp;Changes/improvements <br>:are welcomed. <br><br>&nbsp; &nbsp; Maybe also throw up some suggestions when using HAMMER, like <br>&nbsp; &nbsp; chflags'ing it all nohistory and making sure the filesystem is <br>&nbsp; &nbsp; given enough pruning time in the config. <br><br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; -Matt <br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Matthew Dillon <br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26771837&i=0" target="_top" rel="nofollow">dillon@...</a>&gt; <br> tag:old.nabble.com,2006:post-26761240 2009-12-12T13:13:12Z 2009-12-12T13:13:12Z Justin C. Sherrill I've got the wrapper script I use for building and uploading all of pkgsrc <br>on DragonFly cleaned up, and I put together a web page for it: <br><br><a href="http://www.shiningsilence.com/simplepbulk/" target="_top" rel="nofollow">http://www.shiningsilence.com/simplepbulk/</a><br><br>It's a few shell scripts, so it's easy to look at. &nbsp;Changes/improvements <br>are welcomed. <br><br> tag:old.nabble.com,2006:post-26660659 2009-12-05T15:35:28Z 2009-12-05T15:35:28Z Matthew Dillon &nbsp; &nbsp; Ok, I committed the patch with one additinal change which is to <br>&nbsp; &nbsp; comment out the assertion causing the reported IPV6 issues. <br><br>&nbsp; &nbsp; I tracked it down but can't fix it right now. &nbsp;Basically what is <br>&nbsp; &nbsp; happening is that IPV6 packets are being forwarded to the &quot;netisr_cpu 0&quot; <br>&nbsp; &nbsp; thread, so some of the UDP and TCP processing is taking place there <br>&nbsp; &nbsp; instead of in the tcp or udp protocol threads. &nbsp;Actually, I think it <br>&nbsp; &nbsp; might be taking place in both threads (on the same cpu) which might <br>&nbsp; &nbsp; create its own issues. <br><br>&nbsp; &nbsp; The chain of events starts with the netisr_register() call made in <br>&nbsp; &nbsp; netinet6/ip6_input.c and fans out from there. <br><br>&nbsp; &nbsp; The tcp timer assertions are being left intact as they assert the <br>&nbsp; &nbsp; caller is on the correct cpu, which we are even though we are in the <br>&nbsp; &nbsp; wrong protocol thread. <br><br>&nbsp; &nbsp; I think that will work out for now. &nbsp;What we really need to do is <br>&nbsp; &nbsp; implement a proper ip6_demux.c which would then forward the packets <br>&nbsp; &nbsp; to (at least) the proper protocol threads instead of the <br>&nbsp; &nbsp; &quot;netisr_cpu 0&quot; protocol thread. <br><br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; -Matt <br><br> tag:old.nabble.com,2006:post-26549806 2009-11-27T17:32:36Z 2009-11-27T17:32:36Z Sdävtaker i guess that you can call an script in your crontab that does <br>something like this: <br>if( last_date_script_was_ran &lt; today || last_date_script_was_run == null) then <br>&nbsp; &nbsp; run clean up && last_day_script_was_run := today <br>fi <br>you can save the last_day_script_was_run in /var/log maybe. <br><br>a little more complex, maybe the &quot;last_time_cleanup_was_run_on_me&quot; can <br>be recorded in pfs metadata (if it is not there already) &nbsp;and you can <br>add a parameter to &quot;hammer cleanup&quot; so you tell it to run only if &quot;x <br>time passed since last run&quot;. <br><br>Damian <br><br><br>On Sun, Nov 22, 2009 at 10:59, Thomas Nikolajsen <br>&lt;<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26549806&i=0" target="_top" rel="nofollow">thomas.nikolajsen@...</a>&gt; wrote: <div class='shrinkable-quote'><br>&gt; We need by default to run 'hammer cleanup' every day system is running; <br>&gt; also on systems not running at night. <br>&gt; <br>&gt; Otherwise snapshots won't be generated and HAMMER file system fills up. <br>&gt; This will result in users not having the benefits from HAMMER they could. <br>&gt; <br>&gt; Our present default setup is to run 'hammer cleanup' daily by periodic(8), <br>&gt; which runs by default every night at 3 AM (via /etc/crontab). <br>&gt; This is nice for systems running every night, typically servers. <br>&gt; But it doesn't help newbies running systems not running every night. <br>&gt; <br>&gt; A year ago we had a good discussion on this topic; <br>&gt; many good ideas and viewpoint were presented, see <br>&gt; <a href="http://leaf.dragonflybsd.org/mailarchive/kernel/2008-10/index.html#00051" target="_top" rel="nofollow">http://leaf.dragonflybsd.org/mailarchive/kernel/2008-10/index.html#00051</a><br>&gt; <br>&gt; I suggest that we by default run periodic(8) at reboot, delayed by 30 minutes. <br>&gt; (periodic(8) run in background, like present default) <br>&gt; <br>&gt; This will by default run 'hammer cleanup' (by periodic/daily/160.clean-hammer), <br>&gt; and also the other nice functionalities in the periodic(8) scripts, <br>&gt; that systems not running at night in our present default setup won't run at all. <br>&gt; Defaults, running periodic(8) at all and delay period, can be adjusted by user, <br>&gt; and periodic(8) daily shall not run multiple times a day, this has to be handled. <br>&gt; <br>&gt; Doing this for a year, just using anacron(8), including periodic(8) in anacrontab, <br>&gt; using a delay of a few minutes, I haven't seen any problems. <br>&gt; (This is close to fulfill above requirements(*), good enough for my test) <br>&gt; Anacron(8) doesn't fulfill requirements fully and can't be used in DragonFly base <br>&gt; anyway (GPL licensed), but it is quite simple functionality, that we can write <br>&gt; ourselves, I could do it if we like it. <br>&gt; <br>&gt; * periodic(8) can be run more than once a day: if system is running at 3 AM and <br>&gt; is rebooted later the same day periodic(8) will run twice; this is rare in my use. <br>&gt; <br>&gt;  -thomas <br>&gt; </div><br><br><br>-- <br><a href="http://dfbsd.trackbsd.org.ar" target="_top" rel="nofollow">http://dfbsd.trackbsd.org.ar</a><br> tag:old.nabble.com,2006:post-26510913 2009-11-25T02:59:35Z 2009-11-25T02:59:35Z Simon 'corecode' Schubert [X-Post to kernel@ for discussion] <br><br>Jan Lentfer wrote: <br>&gt; there was some discussion on irc about where README.DRAGONFLY and <br>&gt; README.DELETED had to go. <br>&gt; <br>&gt; I have left it the way I did it of vendor/LESS and as it was sugested on <br>&gt; irc (README.DRAGONFLY on master, README.DELETED on vendor). <br>&gt; <br>&gt; But generally this should be clarified and the consensus should make <br>&gt; it's way into development(7). <br><br>Yes, we should decide. &nbsp;But both should be on the same branch, for <br>coherency. <br><br>Reasons for master: <br>- those files don't belong to the tar ball <br><br>Reasons for vendor branch: <br>- the READMEs describe the files (and what was removed) of the tar ball <br><br>I don't mind either, just coherency. &nbsp;I propose to decide on what goes <br>where first, and after that do the import. &nbsp;Or at least pack both files <br>into the same branch. <br><br>cheers <br>&nbsp; &nbsp;simon <br> tag:old.nabble.com,2006:post-26465585 2009-11-22T05:59:04Z 2009-11-22T05:59:04Z Thomas Nikolajsen We need by default to run 'hammer cleanup' every day system is running; <br>also on systems not running at night. <br><br>Otherwise snapshots won't be generated and HAMMER file system fills up. <br>This will result in users not having the benefits from HAMMER they could. <br><br>Our present default setup is to run 'hammer cleanup' daily by periodic(8), <br>which runs by default every night at 3 AM (via /etc/crontab). <br>This is nice for systems running every night, typically servers. <br>But it doesn't help newbies running systems not running every night. <br><br>A year ago we had a good discussion on this topic; <br>many good ideas and viewpoint were presented, see <br><a href="http://leaf.dragonflybsd.org/mailarchive/kernel/2008-10/index.html#00051" target="_top" rel="nofollow">http://leaf.dragonflybsd.org/mailarchive/kernel/2008-10/index.html#00051</a><br><br>I suggest that we by default run periodic(8) at reboot, delayed by 30 minutes. <br>(periodic(8) run in background, like present default) <br><br>This will by default run 'hammer cleanup' (by periodic/daily/160.clean-hammer), <br>and also the other nice functionalities in the periodic(8) scripts, <br>that systems not running at night in our present default setup won't run at all. <br>Defaults, running periodic(8) at all and delay period, can be adjusted by user, <br>and periodic(8) daily shall not run multiple times a day, this has to be handled. <br><br>Doing this for a year, just using anacron(8), including periodic(8) in anacrontab, <br>using a delay of a few minutes, I haven't seen any problems. <br>(This is close to fulfill above requirements(*), good enough for my test) <br>Anacron(8) doesn't fulfill requirements fully and can't be used in DragonFly base <br>anyway (GPL licensed), but it is quite simple functionality, that we can write <br>ourselves, I could do it if we like it. <br><br>* periodic(8) can be run more than once a day: if system is running at 3 AM and <br>is rebooted later the same day periodic(8) will run twice; this is rare in my use. <br><br>&nbsp;-thomas <br> tag:old.nabble.com,2006:post-26463972 2009-11-22T01:57:26Z 2009-11-22T01:57:26Z Thomas Nikolajsen &gt;&gt; &nbsp; &nbsp;Yah, please upload it. &nbsp;I can't reproduce it trivially, ssh <br>&gt;&gt; localhost is working on my test box. <br>&gt; <br>&gt;Uploaded to *.5 on leaf. <br>&gt; <br>&gt;This is a custom kernel (includes INCLUDE_CONFIG_FILE); <br>&gt;I tried to build GENERIC also, to test on that, but buildkernel failed, <br>&gt;haven't had time to find cause yet <br>&gt;(so my local repo/checkout might be hosed, or whatever). <br><br>GENERIC+SMP (GENERIC w/ SMP & APIC_IO enabled) gives same panic; <br>only with ipv6, as YONETANI suggested: 'ssh -6 ::1' panics <br>('ssh -4 127.0.0.1' works). <br><br>Same for GENERIC, after a minor snafu in patch is corrected: <br>UP kernel doesn't build with patch applied. <br>(in sys/netinet/udp_usrreq.c udp_connect_oncpu() use has problem) <br><br>&nbsp;-thomas <br> tag:old.nabble.com,2006:post-26404135 2009-11-18T00:21:40Z 2009-11-18T00:21:40Z Thomas Nikolajsen What is recommended setup for HAMMER snapshot access from NFS client? <br><br>It would be nice if we got a default setup, so it just worked out of the box. <br><br>With HAMMER version 3 we got easy default slave PFS snapshot location, nice. <br>But this moved dir with snapshots symlinks out of PFS (as needed for slave PFS), <br>which makes access from NFS client more convoluted. <br><br>Solution I can come up with is a bit convoluted: <br>NFS export /var/hammer, and make small script to convert snapshot symlink, <br>producing something like &lt;NFS-client-PFS-mount&gt;@@&lt;tid&gt;. <br><br>In HAMMER version 2-, I make symlinks with relative path names: <br>in snapshots/rel: ../../@@&lt;tid&gt; <br><br>Ahh this idea could be used on HAMMER version 3: e.g.: <br>client# mount -t nfs srv:/PFS /LOCAL <br>client# mount -t nfs srv:/var/hammer/HAMMER/PFS /LOCAL/snapshots <br>will give access to snapshots as /LOCAL/hammer/rel/snap-... <br>(rel/ could also be symlinked from /var/hammer/remote/LOCAL on client) <br>´snapshots´ could be another name if it collides with HAMMER version 2- use. <br>Generating the rel/ symlinks could be part of ´hammer cleanup´. <br><br>Any more straight forward ideas? <br><br>&nbsp;-thomas <br> tag:old.nabble.com,2006:post-26404111 2009-11-18T00:17:04Z 2009-11-18T00:17:04Z Thomas Nikolajsen &gt; &nbsp; &nbsp;Yah, please upload it. &nbsp;I can't reproduce it trivially, ssh <br>&gt; localhost is working on my test box. <br><br>Uploaded to *.5 on leaf. <br><br>This is a custom kernel (includes INCLUDE_CONFIG_FILE); <br>I tried to build GENERIC also, to test on that, but buildkernel failed, <br>haven't had time to find cause yet <br>(so my local repo/checkout might be hosed, or whatever). <br><br>&nbsp;-thomas <br> tag:old.nabble.com,2006:post-26384337 2009-11-16T20:38:45Z 2009-11-16T20:38:45Z Matthew Dillon :&gt; : -thomas <br>:&gt; :- <br>:&gt; :panic: assertion: port=3D&curthread-&gt;td_msgport in syncache socket <br>:&gt; <br>:&gt; &nbsp; &nbsp;Yah, please upload it. &nbsp;I can't reproduce it trivially, ssh localhost <br>:&gt; &nbsp; &nbsp;is working on my test box. <br>: <br>:A-ha, you have to try `ssh ::1', then. &nbsp;You must have `options INET6' <br>:in your kernel config file, of course. <br>: <br>:Cheers. <br><br>&nbsp; &nbsp; Ah, nice guess! &nbsp;But it still works on my test box (Phenom x4) :-(. <br>&nbsp; &nbsp; I'm sure it is a real panic, I just need a kernel core to track <br>&nbsp; &nbsp; down WTF happened. &nbsp;It should be a lot easier to track down these <br>&nbsp; &nbsp; sorts of things now that the port is being stored in the socket <br>&nbsp; &nbsp; structure. <br><br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; -Matt <br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Matthew Dillon <br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26384337&i=0" target="_top" rel="nofollow">dillon@...</a>&gt; <br> tag:old.nabble.com,2006:post-26383303 2009-11-16T18:07:16Z 2009-11-16T18:07:16Z YONETANI Tomokazu-4 On Mon, Nov 16, 2009 at 05:41:01PM -0800, Matthew Dillon wrote: <div class='shrinkable-quote'><br>&gt; <br>&gt; :I have tested patch for some days, and was going to write that I see no iss= <br>&gt; :ues, <br>&gt; :when I got a panic (consistent): 'ssh localhost' panics immediately. <br>&gt; : <br>&gt; :kgdb doesn't show panic message when kernel & core dump loaded; <br>&gt; :will upload to leaf if it is of any use. <br>&gt; : <br>&gt; :SMP kernel used, with HEAD from today. <br>&gt; : <br>&gt; : -thomas <br>&gt; :- <br>&gt; :panic: assertion: port=3D&curthread-&gt;td_msgport in syncache socket <br>&gt; <br>&gt; &nbsp; &nbsp;Yah, please upload it. &nbsp;I can't reproduce it trivially, ssh localhost <br>&gt; &nbsp; &nbsp;is working on my test box. </div><br>A-ha, you have to try `ssh ::1', then. &nbsp;You must have `options INET6' <br>in your kernel config file, of course. <br><br>Cheers. <br> tag:old.nabble.com,2006:post-26383124 2009-11-16T17:41:01Z 2009-11-16T17:41:01Z Matthew Dillon <br>:I have tested patch for some days, and was going to write that I see no iss= <br>:ues, <br>:when I got a panic (consistent): 'ssh localhost' panics immediately. <br>: <br>:kgdb doesn't show panic message when kernel & core dump loaded; <br>:will upload to leaf if it is of any use. <br>: <br>:SMP kernel used, with HEAD from today. <br>: <br>: -thomas <br>:- <br>:panic: assertion: port=3D&curthread-&gt;td_msgport in syncache socket <br><br>&nbsp; &nbsp;Yah, please upload it. &nbsp;I can't reproduce it trivially, ssh localhost <br>&nbsp; &nbsp;is working on my test box. <br><br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; -Matt <br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Matthew Dillon <br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26383124&i=0" target="_top" rel="nofollow">dillon@...</a>&gt; <br> tag:old.nabble.com,2006:post-26381370 2009-11-16T14:51:15Z 2009-11-16T14:51:15Z Thomas Nikolajsen I have tested patch for some days, and was going to write that I see no issues, <br>when I got a panic (consistent): 'ssh localhost' panics immediately. <br><br>kgdb doesn't show panic message when kernel & core dump loaded; <br>will upload to leaf if it is of any use. <br><br>SMP kernel used, with HEAD from today. <br><br>&nbsp;-thomas <br>- <br>panic: assertion: port=&curthread-&gt;td_msgport in syncache socket <br> tag:old.nabble.com,2006:post-26351591 2009-11-14T08:32:27Z 2009-11-14T08:32:27Z Nikita Glukhov &gt; From where is mag_purge() being called? It indeed seems as if the <br>&gt; caller didn't enter the critical section. <br><br>mag_purge() is called from objcache_destroy(). objcache_destroy() as <br>well as maglist_purge() doesn't call crit_enter(). <br> tag:old.nabble.com,2006:post-26349405 2009-11-14T03:48:55Z 2009-11-14T03:48:55Z Alex Hornung Good to hear from you again! <br><br>&gt; Also I don’t understand why Alex Hornung has removed tmpfs_spec_vnops. <br>&gt; Without adding this ops call to mknod() ends with panic. (I have to <br>&gt; run fsstress with option “–f mknod=0”.) <br><br>In short, because of devfs. mknod is not needed, and shouldn't be <br>used, as nodes created with it won't work anyways. <br><br>&gt; Next I tried to use objcache instead of plain kmalloc() to allocate <br>&gt; tmpfs nodes and direntries.  But when objcache is destroyed during <br>&gt; unmount, there is a crit_panic &quot;td_pri is/would-go negative! -26&quot; <br>&gt; caused by mag_purge() calling crit_exit() at objcache.c. It seems that <br>&gt; mag_purge() is not called from the critical section as it is expected. <br><br>From where is mag_purge() being called? It indeed seems as if the <br>caller didn't enter the critical section. <br><br>&gt; 2 diffs to Alex Hornung's tree are attached: first uses kmalloc(), <br>&gt; second uses objcache. <br>&gt; <br><br>When I've some time, I'll add your patches to the repo, but in <br>general, I would recommend you contact Simon &quot;corecode&quot; Schubert or <br>Matt Dillon so you can get a leaf account, where you can keep your own <br>repository. <br><br><br>Cheers, <br>Alex <br> tag:old.nabble.com,2006:post-26348986 2009-11-14T02:39:33Z 2009-11-14T02:39:33Z Nikita Glukhov Hi. <br><br>In July, I’ve fixed file truncating bug. &nbsp;The problem was the lack of <br>a call to vtruncbuf() in tmpfs_reg_resize(). &nbsp;Now tmpfs survives <br>testing with fsx and fsstress. &nbsp;But also I found some bug at <br>fsstress.c: in function creat_f() line 1684 &quot;add_to_flist(type, id, <br>parid);&quot; must be after the following line &quot;#endif&quot;. &nbsp;Without this <br>change fsstress does not remember files that it is created and no <br>reading/writing is performed. (“no filename” error is displayed in <br>verbose mode.) <br><br>Also I don’t understand why Alex Hornung has removed tmpfs_spec_vnops. <br>Without adding this ops call to mknod() ends with panic. (I have to <br>run fsstress with option “–f mknod=0”.) <br><br>Next I tried to use objcache instead of plain kmalloc() to allocate <br>tmpfs nodes and direntries. &nbsp;But when objcache is destroyed during <br>unmount, there is a crit_panic &quot;td_pri is/would-go negative! -26&quot; <br>caused by mag_purge() calling crit_exit() at objcache.c. It seems that <br>mag_purge() is not called from the critical section as it is expected. <br><br>tmpfs now really takes double memory space. I tried to implement page <br>moving between VM objects but I’ve never seen buffer passed to <br>tmpfs_strategy() with B_RELBUF set. All my attempts to modify buffer <br>flags in tmpfs_read() end with global deadlock. <br><br>2 diffs to Alex Hornung's tree are attached: first uses kmalloc(), <br>second uses objcache. <br><br /> <br /> <div class="small"><br/><img src="http://old.nabble.com/images/icon_attachment.gif" > <strong>tmpfs.diff</strong> (23K) <a href="http://old.nabble.com/attachment/26348986/0/tmpfs.diff" target="_top">Download Attachment</a><br/><img src="http://old.nabble.com/images/icon_attachment.gif" > <strong>tmpfs-objcache.diff</strong> (28K) <a href="http://old.nabble.com/attachment/26348986/1/tmpfs-objcache.diff" target="_top">Download Attachment</a></div> tag:old.nabble.com,2006:post-26322085 2009-11-12T08:38:55Z 2009-11-12T08:38:55Z Matthew Dillon <br>:Hi Matt, <br>: <br>:It seems that a hammer fix has slipped into your tcp patch. See the <br>:end of the tcp01.patch: <br><br>&nbsp; &nbsp; Oops. &nbsp;Ok, I took it out. <br><br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; -Matt <br> tag:old.nabble.com,2006:post-26315904 2009-11-12T01:35:39Z 2009-11-12T01:35:39Z Antonio Huete Jimenez Hi Matt, <br><br>It seems that a hammer fix has slipped into your tcp patch. See the <br>end of the tcp01.patch: <br><br>diff --git a/sys/vfs/hammer/hammer_btree.c b/sys/vfs/hammer/hammer_btree.c <br>index 6ee1e1a..050d4a2 100644 <br>--- a/sys/vfs/hammer/hammer_btree.c <br>+++ b/sys/vfs/hammer/hammer_btree.c <br>@@ -2226,9 +2226,10 @@ btree_remove(hammer_cursor_t cursor) <br>... <br><br>Cheers, <br>Antonio Huete <br><br>2009/11/12 Matthew Dillon &lt;<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26315904&i=0" target="_top" rel="nofollow">dillon@...</a>&gt;: <div class='shrinkable-quote'><br>&gt;    Here's a patch, it needs some serious testing: <br>&gt; <br>&gt;        fetch <a href="http://apollo.backplane.com/DFlyMisc/tcp01.patch" target="_top" rel="nofollow">http://apollo.backplane.com/DFlyMisc/tcp01.patch</a><br>&gt; <br>&gt;    The patch: <br>&gt; <br>&gt;        * Moves the socket pointer into the netmsg base structure, even <br>&gt;          though some things don't use it, I know <br>&gt; <br>&gt;        * Adds a lwkt_port pointer to the socket structure and initializes <br>&gt;          it to cpu0_soport() <br>&gt; <br>&gt;        * Expects network protocols to set so-&gt;so_port in their attach <br>&gt;          functions, plus I do that for tcp and udp. <br>&gt; <br>&gt;        * Performs message chasing when the protocol port changes due to <br>&gt;          e.g.  a connect() or an implied connect or (I think) also an <br>&gt;          implied binding to INADDR_ANY. <br>&gt; <br>&gt;          If a number of messages for a socket have built up on a protocol <br>&gt;          thread and some operation in the protocol changes the socket's <br>&gt;          protocol thread (aka implied connect), then any other messages <br>&gt;          queued to that protocol thread, or new messages which race the <br>&gt;          change, will automatically be forwarded to the correct protocol <br>&gt;          thread when they are encountered. <br>&gt; <br>&gt;        * Fixes implied connects for TCP.  This is when you use sendmsg() <br>&gt;          with an address to imply a connect along with data, so data can <br>&gt;          be sent along with the SYN. <br>&gt; <br>&gt;          Implied connects were completely broken and would crash the kernel. <br>&gt;          Example:  finger user@target  (instant crash).  finger uses the <br>&gt;          implied connect feature. <br>&gt; <br>&gt;        * Cleans up a bunch of stuff.  I was almost able to remove <br>&gt;          the proto-&gt;pr_mport field entirely but sendmsg() still needs <br>&gt;          to use it in the case where the passed address is non-NULL (aka <br>&gt;          sendto() style).  All other code that used to call proto-&gt;pr_mport() <br>&gt;          now simply snarf the port out of so-&gt;so_port. <br>&gt; <br>&gt;          The mport functions themselves now basically just return so_port. <br>&gt;          I left the sendmsg code intact just in case we wanted to optimize <br>&gt;          it later on for UDP. <br>&gt; <br>&gt;    I found a few other bugs in the code but haven't fixed them yet.  UDP <br>&gt;    is not MPSAFE due to the global inpcbinfo (udbinfo) structure it uses. <br>&gt; <br>&gt;    This patch does need testing.  I don't know what I might have blown up. <br>&gt;    It's fairly straight forward so I would also appreciate a code review. <br>&gt; <br>&gt;                                                -Matt <br>&gt; <br>&gt; <br></div> tag:old.nabble.com,2006:post-26313165 2009-11-11T20:05:22Z 2009-11-11T20:05:22Z Edward O'Callaghan Looks good Matt, <br><br>Just my quick review, <br>I didn't notice anything obvious, although patch is fairly large. <br><br>Cheers, <br>Edward. <br><br>2009/11/12 Matthew Dillon &lt;<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26313165&i=0" target="_top" rel="nofollow">dillon@...</a>&gt;: <div class='shrinkable-quote'><br>&gt;    Here's a patch, it needs some serious testing: <br>&gt; <br>&gt;        fetch <a href="http://apollo.backplane.com/DFlyMisc/tcp01.patch" target="_top" rel="nofollow">http://apollo.backplane.com/DFlyMisc/tcp01.patch</a><br>&gt; <br>&gt;    The patch: <br>&gt; <br>&gt;        * Moves the socket pointer into the netmsg base structure, even <br>&gt;          though some things don't use it, I know <br>&gt; <br>&gt;        * Adds a lwkt_port pointer to the socket structure and initializes <br>&gt;          it to cpu0_soport() <br>&gt; <br>&gt;        * Expects network protocols to set so-&gt;so_port in their attach <br>&gt;          functions, plus I do that for tcp and udp. <br>&gt; <br>&gt;        * Performs message chasing when the protocol port changes due to <br>&gt;          e.g.  a connect() or an implied connect or (I think) also an <br>&gt;          implied binding to INADDR_ANY. <br>&gt; <br>&gt;          If a number of messages for a socket have built up on a protocol <br>&gt;          thread and some operation in the protocol changes the socket's <br>&gt;          protocol thread (aka implied connect), then any other messages <br>&gt;          queued to that protocol thread, or new messages which race the <br>&gt;          change, will automatically be forwarded to the correct protocol <br>&gt;          thread when they are encountered. <br>&gt; <br>&gt;        * Fixes implied connects for TCP.  This is when you use sendmsg() <br>&gt;          with an address to imply a connect along with data, so data can <br>&gt;          be sent along with the SYN. <br>&gt; <br>&gt;          Implied connects were completely broken and would crash the kernel. <br>&gt;          Example:  finger user@target  (instant crash).  finger uses the <br>&gt;          implied connect feature. <br>&gt; <br>&gt;        * Cleans up a bunch of stuff.  I was almost able to remove <br>&gt;          the proto-&gt;pr_mport field entirely but sendmsg() still needs <br>&gt;          to use it in the case where the passed address is non-NULL (aka <br>&gt;          sendto() style).  All other code that used to call proto-&gt;pr_mport() <br>&gt;          now simply snarf the port out of so-&gt;so_port. <br>&gt; <br>&gt;          The mport functions themselves now basically just return so_port. <br>&gt;          I left the sendmsg code intact just in case we wanted to optimize <br>&gt;          it later on for UDP. <br>&gt; <br>&gt;    I found a few other bugs in the code but haven't fixed them yet.  UDP <br>&gt;    is not MPSAFE due to the global inpcbinfo (udbinfo) structure it uses. <br>&gt; <br>&gt;    This patch does need testing.  I don't know what I might have blown up. <br>&gt;    It's fairly straight forward so I would also appreciate a code review. <br>&gt; <br>&gt;                                                -Matt <br>&gt; <br>&gt; </div><br><br><br>-- <br>-- <br>Edward O'Callaghan <br><a href="http://www.auroraux.org/" target="_top" rel="nofollow">http://www.auroraux.org/</a><br>eocallaghan at auroraux dot org <br> tag:old.nabble.com,2006:post-26312588 2009-11-11T18:45:06Z 2009-11-11T18:45:06Z Matthew Dillon &nbsp; &nbsp; Here's a patch, it needs some serious testing: <br><br>&nbsp; &nbsp; &nbsp; &nbsp; fetch <a href="http://apollo.backplane.com/DFlyMisc/tcp01.patch" target="_top" rel="nofollow">http://apollo.backplane.com/DFlyMisc/tcp01.patch</a><br><br>&nbsp; &nbsp; The patch: <br><br>&nbsp; &nbsp; &nbsp; &nbsp; * Moves the socket pointer into the netmsg base structure, even <br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; though some things don't use it, I know <br><br>&nbsp; &nbsp; &nbsp; &nbsp; * Adds a lwkt_port pointer to the socket structure and initializes <br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; it to cpu0_soport() <br><br>&nbsp; &nbsp; &nbsp; &nbsp; * Expects network protocols to set so-&gt;so_port in their attach <br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; functions, plus I do that for tcp and udp. <br><br>&nbsp; &nbsp; &nbsp; &nbsp; * Performs message chasing when the protocol port changes due to <br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; e.g. &nbsp;a connect() or an implied connect or (I think) also an <br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; implied binding to INADDR_ANY. <br><br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; If a number of messages for a socket have built up on a protocol <br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; thread and some operation in the protocol changes the socket's <br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; protocol thread (aka implied connect), then any other messages <br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; queued to that protocol thread, or new messages which race the <br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; change, will automatically be forwarded to the correct protocol <br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; thread when they are encountered. <br><br>&nbsp; &nbsp; &nbsp; &nbsp; * Fixes implied connects for TCP. &nbsp;This is when you use sendmsg() <br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; with an address to imply a connect along with data, so data can <br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; be sent along with the SYN. <br><br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Implied connects were completely broken and would crash the kernel. <br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Example: &nbsp;finger user@target &nbsp;(instant crash). &nbsp;finger uses the <br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; implied connect feature. <br><br>&nbsp; &nbsp; &nbsp; &nbsp; * Cleans up a bunch of stuff. &nbsp;I was almost able to remove <br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; the proto-&gt;pr_mport field entirely but sendmsg() still needs <br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; to use it in the case where the passed address is non-NULL (aka <br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; sendto() style). &nbsp;All other code that used to call proto-&gt;pr_mport() <br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; now simply snarf the port out of so-&gt;so_port. <br><br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; The mport functions themselves now basically just return so_port. <br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; I left the sendmsg code intact just in case we wanted to optimize <br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; it later on for UDP. <br><br>&nbsp; &nbsp; I found a few other bugs in the code but haven't fixed them yet. &nbsp;UDP <br>&nbsp; &nbsp; is not MPSAFE due to the global inpcbinfo (udbinfo) structure it uses. <br><br>&nbsp; &nbsp; This patch does need testing. &nbsp;I don't know what I might have blown up. <br>&nbsp; &nbsp; It's fairly straight forward so I would also appreciate a code review. <br><br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; -Matt <br><br> tag:old.nabble.com,2006:post-26308177 2009-11-11T12:30:59Z 2009-11-11T12:30:59Z Matthew Dillon &nbsp; &nbsp; I hit another race in the TCP connect code related to implied <br>&nbsp; &nbsp; connects on sendmsg(). <br><br>&nbsp; &nbsp; I am going to be changing the so_mport stuff a bit to improve code <br>&nbsp; &nbsp; flow and fix the issue as well as other issues where sockets have <br>&nbsp; &nbsp; to migrate between cpus. &nbsp;This will also improve performance as the <br>&nbsp; &nbsp; target message port will be cached in the socket structure. &nbsp;It will <br>&nbsp; &nbsp; also allow us to do things like spread unix domain sockets and <br>&nbsp; &nbsp; possibly even socketpairs across multiple cpus. <br><br>&nbsp; &nbsp; I will be storing the target port in the socket structure and will <br>&nbsp; &nbsp; modify the message service loop to forward messages that wind up on <br>&nbsp; &nbsp; the wrong port (due to the protocol changing the port during e.g. <br>&nbsp; &nbsp; a connect()). <br><br>&nbsp; &nbsp; This will remove a ton of special cases. &nbsp;One special case will be <br>&nbsp; &nbsp; added to synchronize port changes. &nbsp;For example, if a ton of sendmsg() <br>&nbsp; &nbsp; calls are made (and the first was for an implied connect), then when <br>&nbsp; &nbsp; the port is changed the socket will have to ensure that no new <br>&nbsp; &nbsp; messages are queued to the new port until all messages sitting on the <br>&nbsp; &nbsp; old port have been properly forwarded. <br><br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; -Matt <br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Matthew Dillon <br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26308177&i=0" target="_top" rel="nofollow">dillon@...</a>&gt; <br> tag:old.nabble.com,2006:post-26292914 2009-11-10T14:48:57Z 2009-11-10T14:48:57Z Sascha Wildner Matthew Dillon schrieb: <div class='shrinkable-quote'><br>&gt; :So my question is: What are my next steps in order to help resolve this <br>&gt; :issue? Is there any way to get e.g. to the names of the files affected <br>&gt; :by this problem from the data which is output by 'hammer show'? <br>&gt; : <br>&gt; :So far the only thing I've done is to disable nightly hammer cleanup <br>&gt; :because DragonFly, upon encountering a CRC error, will unfortunately <br>&gt; :simply drop to the debugger without panicing, so this doesn't get caught <br>&gt; :by DDB_UNATTENDED as far as I can tell (Matt, are there any plans to <br>&gt; :change this unpleasant behavior?). And I won't be near that box until <br>&gt; :next weekend. <br>&gt; : <br>&gt; :Regards, <br>&gt; :Sascha <br>&gt; <br>&gt; &nbsp; &nbsp; I fixed the behavior in current. &nbsp;There is now a sysctl which <br>&gt; &nbsp; &nbsp; controls whether it drops into the debugger or not (and it does not <br>&gt; &nbsp; &nbsp; by default). &nbsp;Though it doesn't panic... maybe the sysctl should be <br>&gt; &nbsp; &nbsp; modified to give it the ability to panic instead of propagating an <br>&gt; &nbsp; &nbsp; error code up the call chain. &nbsp;The filesystem still drops into <br>&gt; &nbsp; &nbsp; read-only mode if an error is encountered. <br>&gt; <br>&gt; &nbsp; &nbsp; What you want to do now is run 'hammer -f ... show | less -B' and <br>&gt; &nbsp; &nbsp; search for B, as in '/^B'. &nbsp;less -B uses a fixed buffer so if you <br>&gt; &nbsp; &nbsp; scroll down you basically cannot scroll back up (by much), which allows <br>&gt; &nbsp; &nbsp; you to pipe gigabytes and gigabytes of text through it without it <br>&gt; &nbsp; &nbsp; malloc()ing itself into oblivion. &nbsp;You want to try to find the problem <br>&gt; &nbsp; &nbsp; area and get more context out of it, such as the object id. &nbsp;And also <br>&gt; &nbsp; &nbsp; to determine whether the problem area is real or not. </div><br>OK, here's some more context from the errors. Is that enough? I fear I'm <br>not used enough to reading hammer show output. I will re-check the <br>filesystem in an unmounted state on the weekend. <br><br>G------ ELM 24 R obj=000000011164da5c key=000000000c250000 lo=00040002 <br>rt=10 ot=02 <br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; tids 0000000111655c50:0000000000000000 <br>B &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;dataoff=a00000714d120000/65536 crc=7e4f7545 <br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; fills=z10:58010=100% <br><br>G------ ELM &nbsp;0 R obj=000000011164da5c key=00000000302e0000 lo=00040002 <br>rt=10 ot=02 <br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; tids 0000000111656eb0:0000000000000000 <br>B &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;dataoff=a000007171380000/65536 crc=616b1cc1 <br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; fills=z10:58082=100% <br><br>obj is the same for both even though they are in different parts of the <br>hammer show output. <br><br>Sascha <br><br>-- <br><a href="http://yoyodyne.ath.cx" target="_top" rel="nofollow">http://yoyodyne.ath.cx</a><br> tag:old.nabble.com,2006:post-26286917 2009-11-10T08:41:18Z 2009-11-10T08:41:18Z Matthew Dillon :Hi, <br>: <br>:ever since the last time I had CRC problems on my router box, I've <br>:developed the habit of doing a daily 'hammer -f /dev/ad4s1d show |& grep <br>:&quot;^B&quot;' to see if any new errors crept up, and today I found: <br>: <br>:yoyodyne# hammer -f /dev/ad4s1d show |& grep &quot;^B&quot; <br>:B &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;dataoff=a00000714d120000/65536 crc=7e4f7545 <br>:B &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;dataoff=a000007171380000/65536 crc=616b1cc1 <br><br>&nbsp; &nbsp; The question is whether it is real or not. &nbsp;If the filesystem is <br>&nbsp; &nbsp; mounted live then the show command could be catching things in <br>&nbsp; &nbsp; odd states. <br><br>:Console log for the recent days is: <br>: <br>:Nov &nbsp;7 03:15:19 &lt;kern.crit&gt; yoyodyne kernel: HAMMER: Warning: rebalance <br>:caught race against propagate <br>:... <br><br>&nbsp; &nbsp; None of those are serious. &nbsp;Basically just debug messages that will <br>&nbsp; &nbsp; be removed soon. &nbsp;The emergency page allocation for BIO is unrelated <br>&nbsp; &nbsp; to the filesystem code. &nbsp;It's also actually just a warning (telling me <br>&nbsp; &nbsp; that something is eating too many free VM pages). <br><br>:So my question is: What are my next steps in order to help resolve this <br>:issue? Is there any way to get e.g. to the names of the files affected <br>:by this problem from the data which is output by 'hammer show'? <br>: <br>:So far the only thing I've done is to disable nightly hammer cleanup <br>:because DragonFly, upon encountering a CRC error, will unfortunately <br>:simply drop to the debugger without panicing, so this doesn't get caught <br>:by DDB_UNATTENDED as far as I can tell (Matt, are there any plans to <br>:change this unpleasant behavior?). And I won't be near that box until <br>:next weekend. <br>: <br>:Regards, <br>:Sascha <br><br>&nbsp; &nbsp; I fixed the behavior in current. &nbsp;There is now a sysctl which <br>&nbsp; &nbsp; controls whether it drops into the debugger or not (and it does not <br>&nbsp; &nbsp; by default). &nbsp;Though it doesn't panic... maybe the sysctl should be <br>&nbsp; &nbsp; modified to give it the ability to panic instead of propagating an <br>&nbsp; &nbsp; error code up the call chain. &nbsp;The filesystem still drops into <br>&nbsp; &nbsp; read-only mode if an error is encountered. <br><br>&nbsp; &nbsp; What you want to do now is run 'hammer -f ... show | less -B' and <br>&nbsp; &nbsp; search for B, as in '/^B'. &nbsp;less -B uses a fixed buffer so if you <br>&nbsp; &nbsp; scroll down you basically cannot scroll back up (by much), which allows <br>&nbsp; &nbsp; you to pipe gigabytes and gigabytes of text through it without it <br>&nbsp; &nbsp; malloc()ing itself into oblivion. &nbsp;You want to try to find the problem <br>&nbsp; &nbsp; area and get more context out of it, such as the object id. &nbsp;And also <br>&nbsp; &nbsp; to determine whether the problem area is real or not. <br><br>&nbsp; &nbsp; Again the filesystem has to be idle and it would be even better if it <br>&nbsp; &nbsp; were offline entirely. <br><br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; -Matt <br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Matthew Dillon <br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26286917&i=0" target="_top" rel="nofollow">dillon@...</a>&gt; <br> tag:old.nabble.com,2006:post-26283873 2009-11-10T05:47:51Z 2009-11-10T05:47:51Z Sascha Wildner Hi, <br><br>ever since the last time I had CRC problems on my router box, I've <br>developed the habit of doing a daily 'hammer -f /dev/ad4s1d show |& grep <br>&quot;^B&quot;' to see if any new errors crept up, and today I found: <br><br>yoyodyne# hammer -f /dev/ad4s1d show |& grep &quot;^B&quot; <br>B &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;dataoff=a00000714d120000/65536 crc=7e4f7545 <br>B &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;dataoff=a000007171380000/65536 crc=616b1cc1 <br><br>Console log for the recent days is: <br><br>Nov &nbsp;7 03:15:19 &lt;kern.crit&gt; yoyodyne kernel: HAMMER: Warning: rebalance <br>caught race against propagate <br>Nov &nbsp;7 03:15:19 &lt;kern.crit&gt; yoyodyne last message repeated 2 times <br>Nov &nbsp;8 03:05:33 &lt;kern.crit&gt; yoyodyne kernel: bio_page_alloc: WARNING <br>emergency page allocation <br>Nov &nbsp;8 03:19:41 &lt;kern.info&gt; yoyodyne kernel: nfs send error 32 for <br>server 192.168.0.10:/backup <br>Nov &nbsp;8 03:19:41 &lt;kern.info&gt; yoyodyne kernel: receive error 54 from nfs <br>server 192.168.0.10:/backup <br>Nov &nbsp;9 03:56:32 &lt;kern.crit&gt; yoyodyne kernel: Warning: vfsync_bp skipping <br>dirty buffer 0xc2706098 <br>Nov &nbsp;9 03:57:03 &lt;kern.crit&gt; yoyodyne kernel: Warning: vfsync_bp skipping <br>dirty buffer 0xc26eb26c <br><br>smartctl -a /dev/ad4 doesn't report any problems. <br><br>The box is running 2.4.1 (v2.4.1.8.g93de5-RELEASE, to be specific). <br><br>So my question is: What are my next steps in order to help resolve this <br>issue? Is there any way to get e.g. to the names of the files affected <br>by this problem from the data which is output by 'hammer show'? <br><br>So far the only thing I've done is to disable nightly hammer cleanup <br>because DragonFly, upon encountering a CRC error, will unfortunately <br>simply drop to the debugger without panicing, so this doesn't get caught <br>by DDB_UNATTENDED as far as I can tell (Matt, are there any plans to <br>change this unpleasant behavior?). And I won't be near that box until <br>next weekend. <br><br>Regards, <br>Sascha <br><br>-- <br><a href="http://yoyodyne.ath.cx" target="_top" rel="nofollow">http://yoyodyne.ath.cx</a><br> tag:old.nabble.com,2006:post-26261088 2009-11-08T20:09:36Z 2009-11-08T20:09:36Z Matthew Dillon &nbsp; &nbsp; Here's an update on the version 4 WIP testing. <br><br>&nbsp; &nbsp; I pulled the SATA cable on the drive a bunch of times and forced HAMMER <br>&nbsp; &nbsp; to go into crash recovery and it seemed to do a good job. <br><br>&nbsp; &nbsp; I will probably implement the actual REDO as version 5. &nbsp;There's already <br>&nbsp; &nbsp; plenty in version 4 related to the UNDO FIFO changes to support faster <br>&nbsp; &nbsp; flushes and the later REDO to warrent its own version. <br><br>&nbsp; &nbsp; However, I want to do another weeks worth of testing for version 4 <br>&nbsp; &nbsp; to be sure. &nbsp;Version 4 is still WIP and is not yet ready for prime <br>&nbsp; &nbsp; time. <br><br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; -Matt <br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Matthew Dillon <br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26261088&i=0" target="_top" rel="nofollow">dillon@...</a>&gt; <br> tag:old.nabble.com,2006:post-26217467 2009-11-05T07:53:06Z 2009-11-05T07:53:06Z Saifi Khan-6 On Tue, 20 Oct 2009, Simon 'corecode' Schubert wrote: <br><div class='shrinkable-quote'><div class='shrinkable-quote'><br>&gt; Hey, <br>&gt; <br>&gt; the question on which make parallelism to use comes up repeatedly. &nbsp;However <br>&gt; the answer usually is driven by anecdotal evidence and not by empirical data. <br>&gt; To this end, I ran a small benchmark test to add one data point. &nbsp;I have no <br>&gt; idea about confidence intervals, so somebody will have to chime in here. <br>&gt; <br>&gt; <br>&gt; I advise to run builds at -j ncpu+1 for 4-cpu systems. &nbsp;Until we have numbers <br>&gt; for 2-cpu and UP systems, we can not provide conclusive advice, however I <br>&gt; would try using -j3 for those two cases. <br>&gt; </div></div>Hi Simon: <br><br>Please find attached the preliminary results from the first run <br>set on a AMD64 X2 system. <br><br>The data (so far) has been plotted and the generated <br>make-j-runtimes.png is hereby attached. <br><br>Here are the environment details <br><br># uname -a <br>DragonFly amd64x2.datasynergy.org 2.5.1-DEVELOPMENT DragonFly v2.5.1.181.gd15a4-DEVELOPMENT #2: Thu Nov &nbsp;5 20:35:21 IST 2009 &nbsp; &nbsp; <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26217467&i=0" target="_top" rel="nofollow">root@...</a>:/usr/obj/usr/src/sys/AMD64-P-MQ &nbsp;amd64 <br><br><br># swapinfo <br>Device &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;1K-blocks &nbsp; &nbsp; Used &nbsp; &nbsp;Avail Capacity &nbsp;Type <br>/dev/ad4s1b &nbsp; &nbsp; &nbsp; 4194176 &nbsp; &nbsp; 9996 &nbsp;4184180 &nbsp; &nbsp; 0% &nbsp; &nbsp;Interleaved <br><br><br># top snapshot <br>load averages: &nbsp;3.92, &nbsp;3.47, &nbsp;3.15 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; <br>up 0+11:45:23 &nbsp;08:33:37 <br>38 processes: &nbsp;38 running <br>CPU0 states: 37.0% user, &nbsp;0.0% nice, &nbsp;3.9% system, &nbsp;0.0% interrupt, 59.1% idle <br>CPU1 states: 49.2% user, &nbsp;0.0% nice, 18.2% system, &nbsp;0.0% interrupt, 32.6% idle <br>Mem: 142M Active, 552M Inact, 478M Wired, 60M Cache, 167M Buf, 608M Free <br>Swap: 4096M Total, 9996K Used, 4086M Free <br><br><br># vmstat -w 5 <br>&nbsp;procs &nbsp; &nbsp; &nbsp;memory &nbsp; &nbsp; &nbsp;page &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;disks &nbsp; &nbsp; faults &nbsp; &nbsp; &nbsp;cpu <br>&nbsp;r b w &nbsp; &nbsp; avm &nbsp; &nbsp;fre &nbsp;flt &nbsp;re &nbsp;pi &nbsp;po &nbsp;fr &nbsp;sr ad4 md0 &nbsp; in &nbsp; sy &nbsp;cs us sy id <br>&nbsp;5 1 0 &nbsp;203824 754532 14568 &nbsp; 1 &nbsp; 0 &nbsp; 0 14684 278 &nbsp; 0 &nbsp; 0 &nbsp;921 10126 5508 26 &nbsp;8 66 <br>&nbsp;5 2 0 &nbsp;161512 788848 28303 &nbsp; 0 &nbsp; 0 &nbsp; 0 30109 &nbsp; 0 &nbsp; 0 &nbsp; 0 &nbsp;647 8186 8301 85 12 &nbsp;2 <br>&nbsp;4 0 0 &nbsp;287640 677560 26282 &nbsp; 0 &nbsp; 0 &nbsp; 0 20797 &nbsp; 0 &nbsp; 0 &nbsp; 0 &nbsp;639 7012 6691 86 11 &nbsp;2 <br>&nbsp;4 0 0 &nbsp;182192 767152 27185 &nbsp; 0 &nbsp; 0 &nbsp; 0 31759 &nbsp; 0 &nbsp; 0 &nbsp; 0 &nbsp;646 7565 7178 85 13 &nbsp;2 <br>&nbsp;4 0 0 &nbsp;325100 645208 25646 &nbsp; 0 &nbsp; 0 &nbsp; 0 19628 &nbsp; 0 &nbsp; 0 &nbsp; 0 &nbsp;640 6893 6090 88 11 &nbsp;1 <br><br><br># vmstat -s <br><br>234673986 cpu context switches <br>&nbsp;39075925 device interrupts <br>&nbsp; 3455565 software interrupts <br>&nbsp; &nbsp; &nbsp; &nbsp; 0 traps <br>430276210 system calls <br>&nbsp; &nbsp; &nbsp; &nbsp; 1 kernel threads created <br>&nbsp; 1010795 &nbsp;fork() calls <br>&nbsp; 1268091 vfork() calls <br>&nbsp; &nbsp; &nbsp; &nbsp; 0 rfork() calls <br>&nbsp; 2444061 exec() calls <br>&nbsp; &nbsp; &nbsp; 386 swap pager pageins <br>&nbsp; &nbsp; &nbsp; 803 swap pager pages paged in <br>&nbsp; &nbsp; &nbsp;1528 swap pager pageouts <br>&nbsp; &nbsp; &nbsp;3580 swap pager pages paged out <br>&nbsp; &nbsp; &nbsp;7220 vnode pager pageins <br>&nbsp; &nbsp; 16381 vnode pager pages paged in <br>&nbsp; &nbsp; &nbsp; &nbsp; 0 vnode pager pageouts <br>&nbsp; &nbsp; &nbsp; &nbsp; 0 vnode pager pages paged out <br>&nbsp; &nbsp; &nbsp; 251 page daemon wakeups <br>&nbsp;11719895 pages examined by the page daemon <br>&nbsp; &nbsp; 29072 pages reactivated <br>&nbsp;44311304 copy-on-write faults <br>&nbsp; &nbsp; &nbsp; &nbsp; 0 copy-on-write optimized faults <br>530080912 zero fill pages zeroed <br>&nbsp;14409435 zero fill pages prezeroed <br>&nbsp; &nbsp; &nbsp;1088 intransit blocking page faults <br>619469650 total VM faults taken <br>&nbsp; &nbsp; &nbsp; &nbsp; 0 pages affected by kernel thread creation <br>&nbsp;64643286 pages affected by &nbsp;fork() <br>&nbsp;50198608 pages affected by vfork() <br>&nbsp; &nbsp; &nbsp; &nbsp; 0 pages affected by rfork() <br>624395522 pages freed <br>&nbsp; 3153399 pages freed by daemon <br>192851424 pages freed by exiting processes <br>&nbsp; &nbsp; 55712 pages active <br>&nbsp; &nbsp;178325 pages inactive <br>&nbsp; &nbsp; 14227 pages in VM cache <br>&nbsp; &nbsp;130817 pages wired down <br>&nbsp; &nbsp; 92092 pages free <br>&nbsp; &nbsp; &nbsp;4096 bytes per page <br>712512521 total name lookups <br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; cache hits (91% pos + 8% neg) system 0% per-directory <br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; deletions 0%, falsehits 0%, toolong 0% <br><br><br># Application load profile <br><br>The system is running the following applications <br>&nbsp;. ssh daemon <br>&nbsp;. csh shell <br>&nbsp;. make <br><br><br>Please review and let me know if there is any tweak/correction <br>that you deem necessary. <br><br><br>thanks <br>Saifi.<br /> <div class="small"><br/><img src="http://old.nabble.com/images/icon_attachment.gif" > <strong>make-j-runtimes.png</strong> (6K) <a href="http://old.nabble.com/attachment/26217467/0/make-j-runtimes.png" target="_top">Download Attachment</a></div> tag:old.nabble.com,2006:post-26216306 2009-11-05T06:53:14Z 2009-11-05T06:53:14Z Stathis Kamperis-2 2009/11/4 Stathis Kamperis &lt;<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26216306&i=0" target="_top" rel="nofollow">ekamperi@...</a>&gt;: <div class='shrinkable-quote'><br>&gt; Hello everyone! <br>&gt; <br>&gt; I'd like to mark mq*() syscall as MPSAFE, but before that I need <br>&gt; someone to test them in an SMP capable machine running SMP kernel. I <br>&gt; only have UP machines around. <br>&gt; <br>&gt; So, if anyone is able and kind enough, here are some directions on how <br>&gt; to do it. I assume s\he is running HEAD. <br>&gt; <br>&gt; cd /usr/src <br>&gt; fetch <a href="http://leaf.dragonflybsd.org/~beket/mq-mpsafe.diff" target="_top" rel="nofollow">http://leaf.dragonflybsd.org/~beket/mq-mpsafe.diff</a><br>&gt; git apply mq-mpsafe.diff <br>&gt; make buildkernel <br>&gt; make installkernel <br>&gt; reboot <br>&gt; git clone git://gitweb.dragonflybsd.org/~beket/pcca-tests.git <br>&gt; cd pcca-tests/mqueue.h <br>&gt; make && make -k run <br>&gt; cd etc <br>&gt; make <br>&gt; sysctl -w kern.mqueue.mq_prio_max=200 <br>&gt; ./t_mq_parallel_threads <br>&gt; ./t_mq_parallel_fork </div><br>Unfortunately, I forgot to mention one crucial step. After the patch <br>application one should type 'make sysent' inside sys/kern, so that the <br>syscall-related files be regenerated, namely the init_sysent.c. Or <br>even better, *I* should have added the init_sysent.c changes in my <br>patch. Since buildkernel doesn't regenerate these files automatically, <br>I'm afraid that the tests ran with giant lock held upon syscall <br>invocation. <br><br>I apologize for wasting people`s time :( &nbsp;I'll just try to get <br>physical access on an SMP cabable machine & run them on my own. <br><br>Thank you both. <br><br>Best regardis, <br>Stathis Kamperis <br> tag:old.nabble.com,2006:post-26208852 2009-11-04T19:34:19Z 2009-11-04T19:34:19Z Stathis Kamperis-2 2009/11/5 Stathis Kamperis &lt;<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26208852&i=0" target="_top" rel="nofollow">ekamperi@...</a>&gt;: <br>&gt; Second, we don't expose the real values for MQ_OPEN_MAX, MQ_PRIO_MAX <br>&gt; and _POSIX_MESSAGE_PASSING. <br>In the sysconf() level that is. <br> tag:old.nabble.com,2006:post-26208850 2009-11-04T19:32:11Z 2009-11-04T19:32:11Z Stathis Kamperis-2 &gt; Oh, t_mq_send failed at line 56 after raising kern.mqueue.mq_prio_max to 200, <br>&gt; but if I put it back to default (32), the test passes. Is it expected too? <br>Thanks for discovering a double defect :) <br><br>First, my test case uses the MQ_PRIO_MAX constant (default 32) as <br>defined in sys/mqueue.h to figure out the largest possible value for <br>message queue priorities. <br><br>This is wrong. <br>It should get the value via sysconf() and _SC_MQ_PRIO_MAX. That said, <br>when you set max priorities to 200, the test assumed that 32 was the <br>largest possible value and that 2*32 would certainly be an invalid <br>priority value. And it expected mq_send(..., 64); to fail, which it <br>didn't since the real upper value for priorities was 200. When you <br>restored the limit to its default value, 64 was a &quot;legitimate invalid&quot; <br>value and the test passed. <br><br>Second, we don't expose the real values for MQ_OPEN_MAX, MQ_PRIO_MAX <br>and _POSIX_MESSAGE_PASSING. <br><br>I'll fix both of them tomorrow. <br><br>&gt; <br>&gt; Cheers. <br>&gt; <br><br>Thanks, for once more. <br><br><br>Best regards, <br>Stathis Kamperis <br> tag:old.nabble.com,2006:post-26207511 2009-11-04T16:50:25Z 2009-11-04T16:50:25Z YONETANI Tomokazu-4 On Thu, Nov 05, 2009 at 01:55:33AM +0200, Stathis Kamperis wrote: <div class='shrinkable-quote'><br>&gt; &gt; Are we suppose to perform the tests (make -k run and the last two lines) <br>&gt; &gt; as root or a non-root user? 〓I just tried that on vkernel, but if I run <br>&gt; As non-root. <br>&gt; (All the tests in the repository assume non-root runtime context. I <br>&gt; should have mentioned that, sorry.) <br>&gt; <br>&gt; &gt; them as root, t_mq_open, t_mq_open_umask dump core, and any subsequent <br>&gt; &gt; runs dump core too, no matter run as root or not. 〓The version of <br>&gt; That's &quot;expected&quot;. <br>&gt; <br>&gt; When the tests failed for the first time (due to being ran as root) , <br>&gt; the message queues remained in the system. So every subsequent attempt <br>&gt; to run the tests again, failed because those queues were already <br>&gt; present (opened) in the system. I will fix it by installing a signal <br>&gt; handler that cleans up the mess upon SIGABRT. (Actually, IIRC, some <br>&gt; tests may already have such a thing.) </div><br>OK, thanks for the explanation. <br><br>&gt; Most important is that vkernel didn't crash or hang :) <br>&gt; I assume that you didn't pass -n1 to the vkernel, right ? <br><br>I used -n3 and -n16 but vkernel didn't crash or hang in either cases, <br>so I tried it on the real kernel too, but so far all tests ran fine and <br>I haven't managed to crash :). <br>Oh, t_mq_send failed at line 56 after raising kern.mqueue.mq_prio_max to 200, <br>but if I put it back to default (32), the test passes. Is it expected too? <br><br>Cheers. <br> tag:old.nabble.com,2006:post-26206927 2009-11-04T15:55:33Z 2009-11-04T15:55:33Z Stathis Kamperis-2 2009/11/5 YONETANI Tomokazu &lt;<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26206927&i=0" target="_top" rel="nofollow">qhwt+dfly@...</a>&gt;: <br>&gt; Hi, <br>Hi Yonetani & thank you for bothering! <br><div class='shrinkable-quote'><br>&gt; On Wed, Nov 04, 2009 at 02:30:38PM +0200, Stathis Kamperis wrote: <br>&gt;&gt; git clone git://gitweb.dragonflybsd.org/~beket/pcca-tests.git <br>&gt;&gt; cd pcca-tests/mqueue.h <br>&gt;&gt; make && make -k run <br>&gt;&gt; cd etc <br>&gt;&gt; make <br>&gt;&gt; sysctl -w kern.mqueue.mq_prio_max=200 <br>&gt;&gt; ./t_mq_parallel_threads <br>&gt;&gt; ./t_mq_parallel_fork <br>&gt; <br>&gt; Are we suppose to perform the tests (make -k run and the last two lines) <br>&gt; as root or a non-root user?  I just tried that on vkernel, but if I run </div>As non-root. <br>(All the tests in the repository assume non-root runtime context. I <br>should have mentioned that, sorry.) <br><br>&gt; them as root, t_mq_open, t_mq_open_umask dump core, and any subsequent <br>&gt; runs dump core too, no matter run as root or not.  The version of <br>That's &quot;expected&quot;. <br><br>When the tests failed for the first time (due to being ran as root) , <br>the message queues remained in the system. So every subsequent attempt <br>to run the tests again, failed because those queues were already <br>present (opened) in the system. I will fix it by installing a signal <br>handler that cleans up the mess upon SIGABRT. (Actually, IIRC, some <br>tests may already have such a thing.) <br><br>Most important is that vkernel didn't crash or hang :) <br>I assume that you didn't pass -n1 to the vkernel, right ? <br><br>&gt; pcca-tests is 0c458bb3cf5d4943093c9b05ca70cc298f09bb46. <br>&gt; <br>&gt; Cheers. <br>&gt; <br><br>Thanks again. <br><br>Best regards, <br>Stathis Kamperis <br> tag:old.nabble.com,2006:post-26206328 2009-11-04T15:01:04Z 2009-11-04T15:01:04Z YONETANI Tomokazu-4 Hi, <br><br>On Wed, Nov 04, 2009 at 02:30:38PM +0200, Stathis Kamperis wrote: <br>&gt; git clone git://gitweb.dragonflybsd.org/~beket/pcca-tests.git <br>&gt; cd pcca-tests/mqueue.h <br>&gt; make && make -k run <br>&gt; cd etc <br>&gt; make <br>&gt; sysctl -w kern.mqueue.mq_prio_max=200 <br>&gt; ./t_mq_parallel_threads <br>&gt; ./t_mq_parallel_fork <br><br>Are we suppose to perform the tests (make -k run and the last two lines) <br>as root or a non-root user? &nbsp;I just tried that on vkernel, but if I run <br>them as root, t_mq_open, t_mq_open_umask dump core, and any subsequent <br>runs dump core too, no matter run as root or not. &nbsp;The version of <br>pcca-tests is 0c458bb3cf5d4943093c9b05ca70cc298f09bb46. <br><br>Cheers. <br> tag:old.nabble.com,2006:post-26195555 2009-11-04T04:30:38Z 2009-11-04T04:30:38Z Stathis Kamperis-2 Hello everyone! <br><br>I'd like to mark mq*() syscall as MPSAFE, but before that I need <br>someone to test them in an SMP capable machine running SMP kernel. I <br>only have UP machines around. <br><br>So, if anyone is able and kind enough, here are some directions on how <br>to do it. I assume s\he is running HEAD. <br><br>cd /usr/src <br>fetch <a href="http://leaf.dragonflybsd.org/~beket/mq-mpsafe.diff" target="_top" rel="nofollow">http://leaf.dragonflybsd.org/~beket/mq-mpsafe.diff</a><br>git apply mq-mpsafe.diff <br>make buildkernel <br>make installkernel <br>reboot <br>git clone git://gitweb.dragonflybsd.org/~beket/pcca-tests.git <br>cd pcca-tests/mqueue.h <br>make && make -k run <br>cd etc <br>make <br>sysctl -w kern.mqueue.mq_prio_max=200 <br>./t_mq_parallel_threads <br>./t_mq_parallel_fork <br><br>If you encounter problems you can mail me off-list to sort them out. I <br>know that it's messy, so no hard feelings if no one volunteers :) <br>Thank you for considering. <br><br>Best regards, <br>Stathis Kamperis <br> tag:old.nabble.com,2006:post-26182633 2009-11-03T08:40:05Z 2009-11-03T08:40:05Z Matthew Dillon <br>:Matthew Dillon wrote: <br>: <br>:&gt; &nbsp; &nbsp; the only real way to test it is by pulling the SATA cable out of the <br>:&gt; &nbsp; &nbsp; drive during heavy disk I/O (do NOT pull the power on a drive), or <br>: <br>:Matt, <br>: <br>:What thoughts in re pulling the (only) cable on a FW or USB-attached drive? <br>:(as it seesm both easier and 'safer' w/r access and/or other-than-fs damage) <br>: <br>:Bill <br><br>&nbsp; &nbsp; It is fairly safe w/ the AHCI driver or the SILI driver. &nbsp;It is not <br>&nbsp; &nbsp; safe with the NATA driver. &nbsp;It may or may not be safe w/ the firewire <br>&nbsp; &nbsp; driver. &nbsp;It all depends on whether the driver properly aborts any <br>&nbsp; &nbsp; in-progress I/Os or not, and whether the filesystem then does the <br>&nbsp; &nbsp; right thing with the error condition. <br><br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; -Matt <br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Matthew Dillon <br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &lt;<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26182633&i=0" target="_top" rel="nofollow">dillon@...</a>&gt; <br>