Re: rc.d script to load kernel modules
On 11 June 2011 22:17, Doug Barton do...@freebsd.org wrote: Howdy, Per discussion on -arch and the svn list about improving boot time and stripping down the kernel to just that-which-cannot-be-modularized I created the attached script to kldload modules that don't need to be in loader.conf. It cut quite a bit of time off my boot, so hopefully it will be useful to others as well. To use it just put everything that is being _load'ed in loader.conf into kld_list in rc.conf[.local]. For example, mine has: kld_list='umass coretemp ichwd linux nvidia if_wpi' If there is agreement that this is a good direction to go I'll be happy to commit this along with the relevant /etc/defaults/rc.conf and rc.conf.5 changes. How do you would suggest set tunables, which are readonly or have no sysctl(8) equivalent after boot-time? AFAIK loader can't set tunable if module is not loaded at boot-time. hth, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: rc.d script to load kernel modules
On Sun, Jun 12, 2011 at 11:11 PM, Eir Nym eir...@gmail.com wrote: On 11 June 2011 22:17, Doug Barton do...@freebsd.org wrote: Howdy, Per discussion on -arch and the svn list about improving boot time and stripping down the kernel to just that-which-cannot-be-modularized I created the attached script to kldload modules that don't need to be in loader.conf. It cut quite a bit of time off my boot, so hopefully it will be useful to others as well. To use it just put everything that is being _load'ed in loader.conf into kld_list in rc.conf[.local]. For example, mine has: kld_list='umass coretemp ichwd linux nvidia if_wpi' If there is agreement that this is a good direction to go I'll be happy to commit this along with the relevant /etc/defaults/rc.conf and rc.conf.5 changes. How do you would suggest set tunables, which are readonly or have no sysctl(8) equivalent after boot-time? AFAIK loader can't set tunable if module is not loaded at boot-time. Not true. Kernel tunables are really not that different (in concept) from kernel-level environment variables. Certainly, they would have less value if one's loading modules at boot (depending when things are done -- i.e. how closely the sysctl pseudo service is run to the proposed kld pseudo service), but sysctls can't be set until the module (or respective OID leaf) has been created by the kernel (somehow, i.e. via driver initialization, etc). Thanks, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: rc.d script to load kernel modules
On 6/12/2011 1:56 AM, Jason Hellenthal wrote: Cutting modules out of the kernel in general does help speed up booting but loading those same modules later in the boot process will just lead you back to the same boot time. Loading modules via loader.conf is many times slower than doing it from disk after the system is partially booted. (As in, 2-3 seconds per module vs. nearly instantaneous for all 6.) I didn't offer my list as an example of what to do, I offered it as a syntax example. I would of course expect people to use appropriate discretion to load things in loader.conf that are necessary for boot. (Of course, the fact that people can easily get this wrong is a strike against the technique.) There is no point in having an _enable for this script because if the kld_list is empty, nothing happens. Doug's solution is what we have been using for a very long time! the loader.conf solution is not practical when it's shared among many hosts -like here where most of the hosts are dataless-, so, moving the not essential ones to rc.conf was the obvious solution. my .5 danny ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: rc.d script to load kernel modules
On 13 June 2011 06:32, Garrett Cooper yaneg...@gmail.com wrote: On Sun, Jun 12, 2011 at 11:11 PM, Eir Nym eir...@gmail.com wrote: On 11 June 2011 22:17, Doug Barton do...@freebsd.org wrote: Howdy, Per discussion on -arch and the svn list about improving boot time and stripping down the kernel to just that-which-cannot-be-modularized I created the attached script to kldload modules that don't need to be in loader.conf. It cut quite a bit of time off my boot, so hopefully it will be useful to others as well. To use it just put everything that is being _load'ed in loader.conf into kld_list in rc.conf[.local]. For example, mine has: kld_list='umass coretemp ichwd linux nvidia if_wpi' If there is agreement that this is a good direction to go I'll be happy to commit this along with the relevant /etc/defaults/rc.conf and rc.conf.5 changes. How do you would suggest set tunables, which are readonly or have no sysctl(8) equivalent after boot-time? AFAIK loader can't set tunable if module is not loaded at boot-time. Not true. Kernel tunables are really not that different (in concept) from kernel-level environment variables. Certainly, they would have less value if one's loading modules at boot (depending when things are done -- i.e. how closely the sysctl pseudo service is run to the proposed kld pseudo service), but sysctls can't be set until the module (or respective OID leaf) has been created by the kernel (somehow, i.e. via driver initialization, etc). Thanks, -Garrett I see, I use tunables and it will be great if I can add tunables for module while load them from user space with rc(8). ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
boot0cfg in future releases.
Hi folks, I haven't see man page for boot0cfg(8) for FreeBSD 9-Current on FreeBSD website, but it exists for 8.x and earlier versions. Is it website bug or this utility will be removed in the future? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: boot0cfg in future releases.
http://svn.freebsd.org/base/head/usr.sbin/boot0cfg/ It is still connected to the build in the previous directory ../ by the Makefile.* foreach arch. Even if, gpart(8) used along with the corresponding files in /boot you can still achieve the same results for a selection menu at boot time whether it be gptboot gptzfsboot etc... On Mon, Jun 13, 2011 at 07:27:13AM +, Eir Nym wrote: Hi folks, I haven't see man page for boot0cfg(8) for FreeBSD 9-Current on FreeBSD website, but it exists for 8.x and earlier versions. Is it website bug or this utility will be removed in the future? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: rc.d script to load kernel modules
On 6/12/11 11:20 PM, Daniel Braniss wrote: On 6/12/2011 1:56 AM, Jason Hellenthal wrote: Cutting modules out of the kernel in general does help speed up booting but loading those same modules later in the boot process will just lead you back to the same boot time. Loading modules via loader.conf is many times slower than doing it from disk after the system is partially booted. (As in, 2-3 seconds per module vs. nearly instantaneous for all 6.) I didn't offer my list as an example of what to do, I offered it as a syntax example. I would of course expect people to use appropriate discretion to load things in loader.conf that are necessary for boot. (Of course, the fact that people can easily get this wrong is a strike against the technique.) There is no point in having an _enable for this script because if the kld_list is empty, nothing happens. Doug's solution is what we have been using for a very long time! the loader.conf solution is not practical when it's shared among many hosts -like here where most of the hosts are dataless-, so, moving the not essential ones to rc.conf was the obvious solution. what would be REALLY cool would be the ability to make loader.conf have some sort of conditional clauses.. e.g. if MAC== 01:02:03:04:05:06 blah my .5 danny ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
panic - Stopped at kdb_enter+0x92: [I2] addl r14=0xffffffffffe1fe38,gp ;;
On ia64 r221488 KDB: enter: panic [ thread pid 1076 tid 100089 ] Stopped at kdb_enter+0x92: [I2]addl r14=0xffe1fe38,gp ;; db - - - - - - - - - - - - Live Console - - - - - - - - - - - - db bt Tracing pid 1076 tid 100089 td 0xe00011d22000 kdb_enter(0x9ffc00913e38, 0x9ffc00913e38, 0x9ffc00351990, 0x793) at kdb_enter+0x92 panic(0x9ffc00914e40, 0x0, 0x9ffc00914e28, 0x9ffc008e8a30, 0x9ffc000 0003ed5f0) at panic+0x2e0 _sleep(0x9ffc00a08a68, 0x0, 0x174, 0x9ffc008e8a30, 0x0) at _sleep+0x120 ipflog_read(0x0, 0xa000c810b360) at ipflog_read+0x1a0 iplread(0xe00011aff658, 0xa000c810b360, 0x9ffc0025d180, 0x58f) at ip lread+0x50 devfs_read_f(0xe00011c59040, 0xa000c810b360, 0xe00010cc5c00, 0x0, 0x e00011d22000) at devfs_read_f+0x100 dofileread(0xe00011d22000, 0x3, 0xe00011c59040, 0xa000c810b360, 0x0, 0x0) at dofileread+0x150 kern_readv(0xe00011d22000, 0x3, 0xa000c810b360) at kern_readv+0x70 read(0xe00011d22000, 0xa000c810b4e8, 0x9ffc003dc9c0, 0x50e) at read+ 0xd0 syscallenter(0xe00011d22000, 0xa000c810b3a0, 0xa000c810b3a8) at sysc allenter+0x4e0 syscall(0xa000c810b4c8, 0xe00011d22000, 0x2000, 0x9ffc007dd880, 0x8, 0x7fffcda4) at syscall+0x60 epc_syscall_return() at epc_syscall_return db db show thread 100089 Thread 100089 at 0xe00011d22000: proc (pid 1076): 0xe00011ec3a70 name: ipmon stack: 0xa000c8104000-0xa000c810bfff flags: 0x4 pflags: 0 state: RUNNING (CPU 0) priority: 120 container lock: sched lock 0 (0x9ffc00a304c0) db Any use? Thanks Anton -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Time keeping Issues with the low-resolution TSC timecounter
I'm experiencing time-related issues that seem to be caused by the low-resolution TSC timecounter (r222866). The problem I noticed first is that it takes unusually long until a key press is repeated. With the default eventtimer (HPET) it seems to take about 4s, which can be slightly improved by switching to i8254. The error beep seems to take longer than usual, too, and the system feels sluggish in general. An effect that is easier to measure is that the system is unable to properly keep the time. Again the problem is less severe when using i8254 instead of HPET: fk@r500 ~ $sudo sysctl kern.eventtimer.timer=HPET kern.eventtimer.timer: i8254 - HPET fk@r500 ~ $while sudo /etc/rc.d/ntpdate onestart; do sleep 1; done Setting date via ntp. 13 Jun 14:30:34 ntpdate[4161]: step time server 72.14.179.211 offset 47.463608 sec Setting date via ntp. 13 Jun 14:30:52 ntpdate[4172]: step time server 178.26.114.66 offset 14.867148 sec Setting date via ntp. 13 Jun 14:31:12 ntpdate[4183]: step time server 178.26.114.66 offset 17.472867 sec Setting date via ntp. 13 Jun 14:31:37 ntpdate[4194]: step time server 72.14.179.211 offset 22.477665 sec Setting date via ntp. 13 Jun 14:31:51 ntpdate[4205]: step time server 178.26.114.66 offset 10.956637 sec Setting date via ntp. 13 Jun 14:32:11 ntpdate[4216]: step time server 178.26.114.66 offset 16.548800 sec ^C fk@r500 ~ $sudo sysctl kern.eventtimer.timer=i8254 kern.eventtimer.timer: HPET - i8254 fk@r500 ~ $while sudo /etc/rc.d/ntpdate onestart; do sleep 1; done Setting date via ntp. 13 Jun 14:32:23 ntpdate[4240]: step time server 178.26.114.66 offset 8.713638 sec Setting date via ntp. 13 Jun 14:32:28 ntpdate[4251]: step time server 178.26.114.66 offset 1.630654 sec Setting date via ntp. 13 Jun 14:32:33 ntpdate[4262]: step time server 178.26.114.66 offset 2.317175 sec Setting date via ntp. 13 Jun 14:32:38 ntpdate[4273]: step time server 178.26.114.66 offset 2.174220 sec Setting date via ntp. 13 Jun 14:32:43 ntpdate[4284]: step time server 178.26.114.66 offset 1.775281 sec Setting date via ntp. 13 Jun 14:32:49 ntpdate[4295]: step time server 178.26.114.66 offset 2.223660 sec Setting date via ntp. 13 Jun 14:32:54 ntpdate[4306]: step time server 208.52.173.46 offset 1.900942 sec ^C fk@r500 ~ $sudo sysctl kern.eventtimer.timer=HPET kern.eventtimer.timer: i8254 - HPET fk@r500 ~ $while sudo /etc/rc.d/ntpdate onestart; do sleep 1; done Setting date via ntp. 13 Jun 14:33:08 ntpdate[4319]: step time server 108.71.253.20 offset 9.740812 sec Setting date via ntp. 13 Jun 14:33:30 ntpdate[4330]: step time server 108.71.253.20 offset 19.046164 sec Setting date via ntp. 13 Jun 14:33:51 ntpdate[4341]: step time server 108.71.253.20 offset 18.489062 sec Setting date via ntp. 13 Jun 14:34:03 ntpdate[4352]: step time server 69.65.40.29 offset 8.659389 sec Setting date via ntp. 13 Jun 14:34:09 ntpdate[4363]: step time server 108.71.253.20 offset 2.868611 sec Setting date via ntp. 13 Jun 14:34:23 ntpdate[4374]: step time server 108.71.253.20 offset 10.798129 sec Setting date via ntp. 13 Jun 14:34:33 ntpdate[4407]: step time server 108.71.253.20 offset 6.919764 sec Setting date via ntp. 13 Jun 14:34:43 ntpdate[4422]: step time server 108.71.253.20 offset 7.135878 sec ^C fk@r500 ~ $sudo sysctl kern.eventtimer.timer=i8254 kern.eventtimer.timer: HPET - i8254 fk@r500 ~ $while sudo /etc/rc.d/ntpdate onestart; do sleep 1; done Setting date via ntp. 13 Jun 14:34:56 ntpdate[4435]: step time server 108.71.253.20 offset 9.596463 sec Setting date via ntp. 13 Jun 14:35:02 ntpdate[4446]: step time server 108.71.253.20 offset 2.137592 sec Setting date via ntp. 13 Jun 14:35:07 ntpdate[4457]: step time server 108.71.253.20 offset 2.435011 sec Setting date via ntp. 13 Jun 14:35:13 ntpdate[4468]: step time server 108.71.253.20 offset 2.631290 sec Setting date via ntp. 13 Jun 14:35:18 ntpdate[4479]: step time server 108.71.253.20 offset 1.909570 sec Setting date via ntp. 13 Jun 14:35:24 ntpdate[4490]: step time server 108.71.253.20 offset 2.398583 sec Setting date via ntp. 13 Jun 14:35:29 ntpdate[4501]: step time server 108.71.253.20 offset 2.264760 sec Setting date via ntp. 13 Jun 14:35:34 ntpdate[4512]: step time server 108.71.253.20 offset 1.808083 sec Setting date via ntp. HPET1 to HPET3 seem to behave similar to HPET or at least the difference isn't significant enough to be obvious without running proper benchmarks. The cpu is: Calibrating TSC clock ... TSC clock: 1995043420 Hz CPU: Intel(R) Core(TM)2 Duo CPU T5870 @ 2.00GHz (1995.04-MHz K8-class CPU) Origin = GenuineIntel Id = 0x6fd Family = 6 Model = f Stepping = 13 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0xe39dSSE3,DTES64,MON,DS_CPL,EST,TM2,SSSE3,CX16,xTPR,PDCM AMD Features=0x20100800SYSCALL,NX,LM AMD Features2=0x1LAHF TSC: P-state invariant, performance statistics With r222866, I get the message:
Re: rc.d script to load kernel modules
On 13 Jun 2011 17:24, Julian Elischer jul...@freebsd.org wrote: On 6/12/11 11:20 PM, Daniel Braniss wrote: On 6/12/2011 1:56 AM, Jason Hellenthal wrote: Cutting modules out of the kernel in general does help speed up booting but loading those same modules later in the boot process will just lead you back to the same boot time. Loading modules via loader.conf is many times slower than doing it from disk after the system is partially booted. (As in, 2-3 seconds per module vs. nearly instantaneous for all 6.) I didn't offer my list as an example of what to do, I offered it as a syntax example. I would of course expect people to use appropriate discretion to load things in loader.conf that are necessary for boot. (Of course, the fact that people can easily get this wrong is a strike against the technique.) There is no point in having an _enable for this script because if the kld_list is empty, nothing happens. Doug's solution is what we have been using for a very long time! the loader.conf solution is not practical when it's shared among many hosts -like here where most of the hosts are dataless-, so, moving the not essential ones to rc.conf was the obvious solution. what would be REALLY cool would be the ability to make loader.conf have some sort of conditional clauses.. e.g. if MAC== 01:02:03:04:05:06 blah Isn't it just a shell script? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: rc.d script to load kernel modules
On Mon, Jun 13, 2011 at 10:00 AM, Chris Rees utis...@gmail.com wrote: On 13 Jun 2011 17:24, Julian Elischer jul...@freebsd.org wrote: On 6/12/11 11:20 PM, Daniel Braniss wrote: On 6/12/2011 1:56 AM, Jason Hellenthal wrote: Cutting modules out of the kernel in general does help speed up booting but loading those same modules later in the boot process will just lead you back to the same boot time. Loading modules via loader.conf is many times slower than doing it from disk after the system is partially booted. (As in, 2-3 seconds per module vs. nearly instantaneous for all 6.) I didn't offer my list as an example of what to do, I offered it as a syntax example. I would of course expect people to use appropriate discretion to load things in loader.conf that are necessary for boot. (Of course, the fact that people can easily get this wrong is a strike against the technique.) There is no point in having an _enable for this script because if the kld_list is empty, nothing happens. Doug's solution is what we have been using for a very long time! the loader.conf solution is not practical when it's shared among many hosts -like here where most of the hosts are dataless-, so, moving the not essential ones to rc.conf was the obvious solution. what would be REALLY cool would be the ability to make loader.conf have some sort of conditional clauses.. e.g. if MAC== 01:02:03:04:05:06 blah Isn't it just a shell script? The values are eval'ed from Forth-code, not /bin/sh -- so it's not a shell script in the way that you're generally used to :). But yes, it could be made conditional. Thanks! -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: rc.d script to load kernel modules
On 13 Jun 2011 18:24, Garrett Cooper yaneg...@gmail.com wrote: On Mon, Jun 13, 2011 at 10:00 AM, Chris Rees utis...@gmail.com wrote: On 13 Jun 2011 17:24, Julian Elischer jul...@freebsd.org wrote: On 6/12/11 11:20 PM, Daniel Braniss wrote: On 6/12/2011 1:56 AM, Jason Hellenthal wrote: Cutting modules out of the kernel in general does help speed up booting but loading those same modules later in the boot process will just lead you back to the same boot time. Loading modules via loader.conf is many times slower than doing it from disk after the system is partially booted. (As in, 2-3 seconds per module vs. nearly instantaneous for all 6.) I didn't offer my list as an example of what to do, I offered it as a syntax example. I would of course expect people to use appropriate discretion to load things in loader.conf that are necessary for boot. (Of course, the fact that people can easily get this wrong is a strike against the technique.) There is no point in having an _enable for this script because if the kld_list is empty, nothing happens. Doug's solution is what we have been using for a very long time! the loader.conf solution is not practical when it's shared among many hosts -like here where most of the hosts are dataless-, so, moving the not essential ones to rc.conf was the obvious solution. what would be REALLY cool would be the ability to make loader.conf have some sort of conditional clauses.. e.g. if MAC== 01:02:03:04:05:06 blah Isn't it just a shell script? The values are eval'ed from Forth-code, not /bin/sh -- so it's not a shell script in the way that you're generally used to :). But yes, it could be made conditional. I was talking about rc.conf is that Forth too? Chris ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: rc.d script to load kernel modules
On Mon, Jun 13, 2011 at 10:40 AM, Chris Rees utis...@gmail.com wrote: On 13 Jun 2011 18:24, Garrett Cooper yaneg...@gmail.com wrote: On Mon, Jun 13, 2011 at 10:00 AM, Chris Rees utis...@gmail.com wrote: On 13 Jun 2011 17:24, Julian Elischer jul...@freebsd.org wrote: On 6/12/11 11:20 PM, Daniel Braniss wrote: On 6/12/2011 1:56 AM, Jason Hellenthal wrote: Cutting modules out of the kernel in general does help speed up booting but loading those same modules later in the boot process will just lead you back to the same boot time. Loading modules via loader.conf is many times slower than doing it from disk after the system is partially booted. (As in, 2-3 seconds per module vs. nearly instantaneous for all 6.) I didn't offer my list as an example of what to do, I offered it as a syntax example. I would of course expect people to use appropriate discretion to load things in loader.conf that are necessary for boot. (Of course, the fact that people can easily get this wrong is a strike against the technique.) There is no point in having an _enable for this script because if the kld_list is empty, nothing happens. Doug's solution is what we have been using for a very long time! the loader.conf solution is not practical when it's shared among many hosts -like here where most of the hosts are dataless-, so, moving the not essential ones to rc.conf was the obvious solution. what would be REALLY cool would be the ability to make loader.conf have some sort of conditional clauses.. e.g. if MAC== 01:02:03:04:05:06 blah Isn't it just a shell script? The values are eval'ed from Forth-code, not /bin/sh -- so it's not a shell script in the way that you're generally used to :). But yes, it could be made conditional. I was talking about rc.conf is that Forth too? No, that's definitely bourne shell, but it breaks some tools like Devin Taske's sysrc, etc if you use that :). I thought you were talking about what gets read in with device.hints / loader.conf / loader.rc. Thanks! -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Time keeping Issues with the low-resolution TSC timecounter
On Monday 13 June 2011 12:44 pm, Fabian Keil wrote: I'm experiencing time-related issues that seem to be caused by the low-resolution TSC timecounter (r222866). The problem I noticed first is that it takes unusually long until a key press is repeated. With the default eventtimer (HPET) it seems to take about 4s, which can be slightly improved by switching to i8254. The error beep seems to take longer than usual, too, and the system feels sluggish in general. An effect that is easier to measure is that the system is unable to properly keep the time. Again the problem is less severe when using i8254 instead of HPET: [SNIP] First of all, please do not mix timecounter issues with eventtimer. They are not directly related. Can you please show me verbose boot messages *without* your patch? Does sysctl kern.timecounter.hardware=HPET help *without* touching eventtimers? Jung-uk Kim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
RE: Heads Up: default NFS server changing to the new one
From: Rick Macklem Well, I doubt you'll find much difference performance wise. An NFS server can be looked as a protocol translator, converting the NFS RPCs into VFS/VOP calls. Performance is largely defined by how well the network stack and/or file system perform. When you set up a server, there are a few things that may help: [..snip..] Yes, I'm seeing little difference performance wise so far (maybe a slight boost on the new code), although I haven't had time to run all the tests that I'd like so I can't tell if it's significant. However, that's good - as long as we're not regressing, I'm happy. I run ZFS exclusively for my SAN's, and I'm familiar with the various tweaks to make it go faster. ZFS and NFS don't play well under ESX due to the ESX client forcing an O_SYNC as I've detailed before, but a quick snip of a few lines in nfs_nfsdport.c to force ioflags to be what I want helps with that in my situation. I was the guy that was bugging you for a switch for that a month ago.. :-) I'm seeing around a 10% improvement when I do that, as it doesn't flog the ZIL as much (I use multiple hardware RAM drives for a ZIL, so they won't get much faster than that) I'm also PXE booting over NFS, and that's working well, both from iPXE and gPXE. My linux clients running parted or clonezilla also don't seem to have any issues with the new NFS server. There's a bit of error/warning chatter between the old FreeBSD NFS servers I haven't upgraded and the new NFS clients, but it all still seems to work, and I plan on upgrading everything across the board to my newer 2011.05.28.15.00.00 build of 9-CURRENT by the end of this week or next. I'm also going to build a clang/llvm version of the new systems for testing on that end of things, as it may be time for me to switch. As for things the nfsd server code can do, I plan on looking at a couple of things, but I don't think those will be in 9.0: - Making MAXBSIZE larger. Even if it is larger than the largest block size supported for the underlying fs, this may help, because it can reduce the # of I/O RPCs. That's interesting. I wonder what size would be good for ZFS? Possibly 128K. I see your definition in nfsport.h. I may fiddle a bit with this myself. I've also been wondering about the performance effect of the malloc's in the nfsvno_write() function - Would it be more efficient to malloc further up, and pass a pointer to it, so we're not always creating and releasing memory for the writes? Possibly malloc the max size at startup, and reuse the memory area. I haven't been that in-depth with compiling in a while however, so I don't recall how easy this will be, or if the tradeoff of passing the pointer will be just as bad. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
