Re: /etc/rc.d/mountcritremote
On Tue, 2010-08-31 at 10:45 -0700, Dirk-WIllem van Gulik wrote: On 31 Aug 2010, at 17:16, Sean Bruno wrote: An issue in testing came up where we were trying to mount NFS directories from the same server, i.e. a machine trying to mount an NFS dir on itself. Because mountcritremote runs before the NFS server is up, we modified the REQUIRES section and appended nfsd. Are you sure that is right for PXE style boots - where this is heavily relied on ? Dw. Not sure. If the nfs server isn't configured to startup, then this is a no-op. I'm not sure what application would be running in a pxeboot environment and run an NFS server. most of our servers are pxeboot'able/dataless. since we rely heavely on NFS - ie. /usr/local - I set early_late_divider to amd (the automounter), and made sure it runs early enough. Probably because we have been running NFS since V0 (pre automount too), booting machines was a nightmare, I refuse to have nfs mounts in fstab. danny ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: nsswitch man page
If you don't mind, as I've worked extensively with nsswitch, I can check the current implementation and provide you a patch to update the docs. On Wed, Sep 1, 2010 at 12:18 AM, Ivan Voras ivo...@freebsd.org wrote: I'm trying to do something with NSS and I see that NetBSD has much better documentation for it: http://www.daemon-systems.org/man/nsdispatch.3.html vs http://www.freebsd.org/cgi/man.cgi?query=nsdispatch From the AUTHORS section on the FreeBSD's page it looks like it is an import of an earlier NetBSD version. Are the implementations still compatible? Could the manpage simply be reimported from NetBSD? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: nsswitch man page
On 09/01/10 08:16, Michael Bushkov wrote: If you don't mind, as I've worked extensively with nsswitch, I can check the current implementation and provide you a patch to update the docs. Of course, go ahead. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: One-shot-oriented event timers management
On Wed, 01 Sep 2010 00:27:36 +0300 Alexander Motin m...@freebsd.org wrote: Gary Jennejohn wrote: On Mon, 30 Aug 2010 13:07:38 +0300 Alexander Motin m...@freebsd.org wrote: Yes, as I have said, at this moment empty ticks skipped only while CPU is in C2/C3 states. In C1 state there is no way to handle lost events on wake up. While it may be not very dangerous, it is not very good. Too bad. I'd say that systems which are limited to C1 don't benefit much (or not at all) from your changes. I've solved it! :) Yup, this definitely reduces the number of inerrupts on my C1-only system :) Now I'm seeing on the order of 100 to 200 interrupts/s instead of around 2300. I'll run this new kernel some more and see how stable it is. Thanks, mav! -- Gary Jennejohn ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: One-shot-oriented event timers management
Alexander Motin wrote: Gary Jennejohn wrote: On Mon, 30 Aug 2010 12:11:48 +0200 OK, this is purely anecdotal, but I'll report it anyway. I was running pretty much all day with the patched kernel and things seemed to be working quite well. Then, after about 7 hours, everything just stopped. I had gkrellm running and noticed that it updated only when I moved the mouse. This behavior leads me to suspect that the timer interrupts had stopped working and the mouse interrupts were causing processes to get scheduled. Unfortunately, I wasn't able to get a dump and had to hit reset to recover. As I wrote above, this is only anecdotal, but I've never seen anything like this before applying the patches. One-shot timers have one weak side: if for some reason timer interrupt getting lost -- there will be nobody to reload the timer. Such cases probably will require special attention. Same funny situation with mouse-driven scheduler happens also if LAPIC timer dies when pre-Core-iX CPU goes to C3 state. I have reproduced the problem locally. It happens more often when ticks are not stopped on idle, like in your original case (or if explicitly enabled by kern.eventtimer.idletick sysctl). I've made some changes to HPET driver, which, I hope, should fix interrupt losses there. Updated patch: http://people.freebsd.org/~mav/timers_oneshot6.patch Patch also includes some optimizations to reduce lock contention. Thanks for testing. -- Alexander Motin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: One-shot-oriented event timers management
On Wed, 01 Sep 2010 13:44:26 +0300 Alexander Motin m...@freebsd.org wrote: Alexander Motin wrote: Gary Jennejohn wrote: On Mon, 30 Aug 2010 12:11:48 +0200 OK, this is purely anecdotal, but I'll report it anyway. I was running pretty much all day with the patched kernel and things seemed to be working quite well. Then, after about 7 hours, everything just stopped. I had gkrellm running and noticed that it updated only when I moved the mouse. This behavior leads me to suspect that the timer interrupts had stopped working and the mouse interrupts were causing processes to get scheduled. Unfortunately, I wasn't able to get a dump and had to hit reset to recover. As I wrote above, this is only anecdotal, but I've never seen anything like this before applying the patches. One-shot timers have one weak side: if for some reason timer interrupt getting lost -- there will be nobody to reload the timer. Such cases probably will require special attention. Same funny situation with mouse-driven scheduler happens also if LAPIC timer dies when pre-Core-iX CPU goes to C3 state. I have reproduced the problem locally. It happens more often when ticks are not stopped on idle, like in your original case (or if explicitly enabled by kern.eventtimer.idletick sysctl). I've made some changes to HPET driver, which, I hope, should fix interrupt losses there. Updated patch: http://people.freebsd.org/~mav/timers_oneshot6.patch Patch also includes some optimizations to reduce lock contention. Thanks for testing. OK, I'll give it a try, althought your previous patch seems to be working quite well. BTW I've also been using tm6292_idle.patch. Do I really need it? -- Gary Jennejohn ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: One-shot-oriented event timers management
Gary Jennejohn wrote: On Wed, 01 Sep 2010 13:44:26 +0300 Alexander Motin m...@freebsd.org wrote: I have reproduced the problem locally. It happens more often when ticks are not stopped on idle, like in your original case (or if explicitly enabled by kern.eventtimer.idletick sysctl). I've made some changes to HPET driver, which, I hope, should fix interrupt losses there. Updated patch: http://people.freebsd.org/~mav/timers_oneshot6.patch Patch also includes some optimizations to reduce lock contention. Thanks for testing. OK, I'll give it a try, althought your previous patch seems to be working quite well. Stopping/starting timer around idle could partially hide the problem. Single external even in such case could be enough to revive system. BTW I've also been using tm6292_idle.patch. Do I really need it? It is not necessary. It just reduces number of events generated by system by hacking several aggressive places I've found. -- Alexander Motin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: One-shot-oriented event timers management
Alexander Leidinger wrote: Quoting Alexander Motin m...@freebsd.org (from Sun, 29 Aug 2010 16:10:00 +0300): I have actively tested this code for a few days on my amd64 Core2Duo laptop and i386 Core-i5 desktop system. With C2/C3 states enabled systems experience only about 100-150 interrupts per second, having HZ set to 1000. These events mostly caused by several event-greedy processes in our tree. I have traced and hacked several most aggressive ones in this patch: http://people.freebsd.org/~mav/tm6292_idle.patch . It allowed me to reduce down to as low as 50 interrupts per system, including IPIs! It looks like you are comming to a point where Powertop would be helpful. There's a dtracified version of it available at the opensolaris site (it would at least need some additional dtrace probes in our kernel). http://hub.opensolaris.org/bin/view/Project+tesla/Powertop Thank you for the link. I was thinking about it, but worried that it could be too Linux-specific. Nice to here there is closer alternative. I'll look on it. PS: Until it is ported, I've found that `top -m io -o vcsw` could also be useful. The only thing it can't show is in-kernel callout(9) calls. User and kernel processes wakeups still nicely visible there. -- Alexander Motin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: One-shot-oriented event timers management
Quoting Alexander Motin m...@freebsd.org (from Sun, 29 Aug 2010 16:10:00 +0300): I have actively tested this code for a few days on my amd64 Core2Duo laptop and i386 Core-i5 desktop system. With C2/C3 states enabled systems experience only about 100-150 interrupts per second, having HZ set to 1000. These events mostly caused by several event-greedy processes in our tree. I have traced and hacked several most aggressive ones in this patch: http://people.freebsd.org/~mav/tm6292_idle.patch . It allowed me to reduce down to as low as 50 interrupts per system, including IPIs! It looks like you are comming to a point where Powertop would be helpful. There's a dtracified version of it available at the opensolaris site (it would at least need some additional dtrace probes in our kernel). http://hub.opensolaris.org/bin/view/Project+tesla/Powertop Bye, Alexander. -- Our customers' paperwork is profit. Our own paperwork is loss. http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: One-shot-oriented event timers management
On Wed, 1 Sep 2010 14:15:41 +0200 Gary Jennejohn gljennj...@googlemail.com wrote: On Wed, 01 Sep 2010 13:44:26 +0300 Alexander Motin m...@freebsd.org wrote: Updated patch: http://people.freebsd.org/~mav/timers_oneshot6.patch Patch also includes some optimizations to reduce lock contention. Thanks for testing. OK, I'll give it a try, althought your previous patch seems to be working quite well. This has changed the behavior of the HPET timers somewhat. With patch5 I was seeing approximately equal interrupt counts from hpet0 and hpet1. Now the majority of interrupts are on hpet0 by a factor of 6 to 10. Not a show stopper, just thought I'd mention it. One difference is that I didn't apply tm6292_idle.patch this time. -- Gary Jennejohn ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: One-shot-oriented event timers management
Gary Jennejohn wrote: On Wed, 1 Sep 2010 14:15:41 +0200 Gary Jennejohn gljennj...@googlemail.com wrote: On Wed, 01 Sep 2010 13:44:26 +0300 Alexander Motin m...@freebsd.org wrote: Updated patch: http://people.freebsd.org/~mav/timers_oneshot6.patch Patch also includes some optimizations to reduce lock contention. Thanks for testing. OK, I'll give it a try, althought your previous patch seems to be working quite well. This has changed the behavior of the HPET timers somewhat. With patch5 I was seeing approximately equal interrupt counts from hpet0 and hpet1. Now the majority of interrupts are on hpet0 by a factor of 6 to 10. Not a show stopper, just thought I'd mention it. One difference is that I didn't apply tm6292_idle.patch this time. That could be the reason. This patch removes up to few hundreds events per second. -- Alexander Motin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: One-shot-oriented event timers management
On Wed, Sep 1, 2010 at 5:44 AM, Alexander Motin m...@freebsd.org wrote: Alexander Motin wrote: Gary Jennejohn wrote: On Mon, 30 Aug 2010 12:11:48 +0200 OK, this is purely anecdotal, but I'll report it anyway. I was running pretty much all day with the patched kernel and things seemed to be working quite well. Then, after about 7 hours, everything just stopped. I had gkrellm running and noticed that it updated only when I moved the mouse. This behavior leads me to suspect that the timer interrupts had stopped working and the mouse interrupts were causing processes to get scheduled. Unfortunately, I wasn't able to get a dump and had to hit reset to recover. As I wrote above, this is only anecdotal, but I've never seen anything like this before applying the patches. One-shot timers have one weak side: if for some reason timer interrupt getting lost -- there will be nobody to reload the timer. Such cases probably will require special attention. Same funny situation with mouse-driven scheduler happens also if LAPIC timer dies when pre-Core-iX CPU goes to C3 state. I have reproduced the problem locally. It happens more often when ticks are not stopped on idle, like in your original case (or if explicitly enabled by kern.eventtimer.idletick sysctl). I've made some changes to HPET driver, which, I hope, should fix interrupt losses there. Updated patch: http://people.freebsd.org/~mav/timers_oneshot6.patch Patch also includes some optimizations to reduce lock contention. Thanks for testing. This latest patch causes an interrupt storm with the HPET timer on my system. The machine took about 8 minutes to boot and bring me to a login prompt. System interactivity (i.e. input from keyboard, output on console) was fine, but after checking the output of `systat vmstat -1`, I saw the interrupt rate on each HPET entry was over 120k! Can I provide any useful detail? Of course, test patches are always welcome :) -Brandon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: expand_number() for fetch'es -B and -S switches
Alexander Best arun...@freebsd.org writes: just having a quick look around to see, if anybody would be interested in fetch -B and fetch -S accepting humanized numbers using expand_number()? I can understand it for -B, but not for -S, since in the common case (by 1023 to 1, assuming a random distribution) the argument to -S can not be expressed in [kMGTEP]B. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
/stand/camcontrol
Consider the following commit: r89471 | joerg | 2002-01-17 21:26:14 +0100 (Thu, 17 Jan 2002) | 8 lines Provide an option to make camcontrol `minimalistic': if the (env/make) variable RELEASE_BUILD_FIXIT is defined, a camcontrol binary will be built that only knows the rescan and reset subcommands. The resulting code is small enough to still fit onto the boot floppy. This makes /stand/camcontrol completely useless. Do we still care about fitting sysinstall on a floppy? The full camcontrol is about 100 kB larger than the pared-down version, but I'm not sure the difference is that big when it's crunched with the rest of /stand. textdata bss dec hex filename 268751 26464 54112 349327 5548f camcontrol-crunch 355122 27064 58904 441090 6bb02 camcontrol-full DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: One-shot-oriented event timers management
Brandon Gooch wrote: This latest patch causes an interrupt storm with the HPET timer on my system. The machine took about 8 minutes to boot and bring me to a login prompt. System interactivity (i.e. input from keyboard, output on console) was fine, but after checking the output of `systat vmstat -1`, I saw the interrupt rate on each HPET entry was over 120k! Can I provide any useful detail? Of course, test patches are always welcome :) I was able to reproduce alike storm in some situations. Try new version: http://people.freebsd.org/~mav/timers_oneshot7.patch -- Alexander Motin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: /stand/camcontrol
2010/9/1 Dag-Erling Smørgrav d...@des.no: Consider the following commit: r89471 | joerg | 2002-01-17 21:26:14 +0100 (Thu, 17 Jan 2002) | 8 lines Provide an option to make camcontrol `minimalistic': if the (env/make) variable RELEASE_BUILD_FIXIT is defined, a camcontrol binary will be built that only knows the rescan and reset subcommands. The resulting code is small enough to still fit onto the boot floppy. This makes /stand/camcontrol completely useless. Do we still care about fitting sysinstall on a floppy? The full camcontrol is about 100 kB larger than the pared-down version, but I'm not sure the difference is that big when it's crunched with the rest of /stand. text data bss dec hex filename 268751 26464 54112 349327 5548f camcontrol-crunch 355122 27064 58904 441090 6bb02 camcontrol-full My 2 cents: I think we don't really need to care about the size for rescue binary after the splitfs VFS layer have been introduced to libstand? Build of release split MFSROOT was 2006-ish and I feel that this can be gone. One of my hope is that we can add bzip2 or even 7zip support to loader, though, which may not fit a floppy though. Cheers, -- Xin LI delp...@delphij.net http://www.delphij.net ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: expand_number() for fetch'es -B and -S switches
On Wed Sep 1 10, Dag-Erling Smørgrav wrote: Alexander Best arun...@freebsd.org writes: just having a quick look around to see, if anybody would be interested in fetch -B and fetch -S accepting humanized numbers using expand_number()? I can understand it for -B, but not for -S, since in the common case (by 1023 to 1, assuming a random distribution) the argument to -S can not be expressed in [kMGTEP]B. you're absolutely correct there. i didn't really think about it. i just thought -B might profit from expand_number() amnd saw that -S was also taking a byte value as argument so i added it to my previous mail. i should have read the description for -S more carefully. ;) since you're the originator of fetch(1): should i send you a patch to add expand_numer() to the -B switch or do you think fetch is better off as it is now without humanised numbers? i'm not sure, but i think fetch(1) is BSD specific so no POSIX regulations need to be taken into consideration. but you probably know more about this matter. cheers. alex DES -- Dag-Erling Smørgrav - d...@des.no -- a13x ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
porting cputick2usec() to userland
hi there, there was a thread some time ago related to porting cputick2usec() to userland [1]. however it seems the idea got lost at some point. i remember uqs working on an implementation, but can't remember the details. a few people including uqs and jhb liked the idea. any comments on that? cheers. alex [1] http://www.mail-archive.com/freebsd-hackers@freebsd.org/msg70400.html -- a13x ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: porting cputick2usec() to userland
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2010/09/01 16:03, Alexander Best wrote: hi there, there was a thread some time ago related to porting cputick2usec() to userland [1]. however it seems the idea got lost at some point. i remember uqs working on an implementation, but can't remember the details. a few people including uqs and jhb liked the idea. any comments on that? I think uqs@ actually have a patch but can't seem to access his git repository anymore for some reason :-/ cheers. alex [1] http://www.mail-archive.com/freebsd-hackers@freebsd.org/msg70400.html - -- Xin LI delp...@delphij.nethttp://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (FreeBSD) iQEcBAEBCAAGBQJMfuB/AAoJEATO+BI/yjfBnwoIAJF+Wu3E8m92PkNmmpdwymU1 BFbtzxZ//MIDmOkrW5qnIjfQPpcnizXX12Le8/6YFbBjP2fDqsn06CwVb6BKX6Kb bJfzMLKIEN/zaGVNmteduHLPL7Y0xv8TKUspk2B7wfpgk3aLCuUH00e3kSHsriwm Cwyoqn+GQs4GC2056bV3LL7PdQec6vfaQtBlBN9+WavHQFbaJsBAOqx+Ekkvu8t7 PcRQlvLyp3ledsO5ezJjlnMsyvu4JAbAv+/RFiODLhLlpiJpa0y8T8cqnA5FLTIj ZAvtW/Adu28H2aMvhRWHT0JzoOVbZWsuK2FCgw9gY4KYXlePeTUk+EJlfN+YWtE= =f55Y -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: One-shot-oriented event timers management
On Wed, Sep 1, 2010 at 2:16 PM, Alexander Motin m...@freebsd.org wrote: Brandon Gooch wrote: This latest patch causes an interrupt storm with the HPET timer on my system. The machine took about 8 minutes to boot and bring me to a login prompt. System interactivity (i.e. input from keyboard, output on console) was fine, but after checking the output of `systat vmstat -1`, I saw the interrupt rate on each HPET entry was over 120k! Can I provide any useful detail? Of course, test patches are always welcome :) I was able to reproduce alike storm in some situations. Try new version: http://people.freebsd.org/~mav/timers_oneshot7.patch Definitely solved it!!! Awesome, BTW, check out my C3 time: # gnu-watch -n1 'sysctl dev.cpu | grep cx_usage' Every 1.0s: sysctl dev.cpu | grep cx_usage Wed Sep 1 17:56:31 2010 dev.cpu.0.cx_usage: 0.00% 0.03% 99.96% last 7159us dev.cpu.1.cx_usage: 0.00% 0.00% 100.00% last 6343us I've now seen my computer at it's lowest battery drain rate yet (around 11000 mW) while using my system. This just keeps getting better and better mav@, hope we see more testers soon :) -Brandon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
RE: Support for WD Advanced Format disks
From: Dag-Erling Smørgrav: Ilya Bakulin webmas...@kibab.com writes: May you suggest any other tests? What other tests? The disks suck, how are more tests going to improve the situation? Or let's live with sucking WD Green and look for other 4096K-sector models from other manufacturers? I see no reason why sector size should be a selection criterium. Just buy the disk that gives you the best performance and / or capacity for your money. WD Green disks are cheap, but other vendors offer models with the same capacity and twice the speed for only 5% or 10% more. Heck, Western Digital themselves offer faster drives that are only a few dollars more. The Green drives are built for low noise/power/heat, not for speed. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
