[head tinderbox] failure on powerpc64/powerpc
TB --- 2010-08-29 06:16:06 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-08-29 06:16:06 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2010-08-29 06:16:06 - cleaning the object tree TB --- 2010-08-29 06:16:20 - cvsupping the source tree TB --- 2010-08-29 06:16:20 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2010-08-29 06:17:00 - building world TB --- 2010-08-29 06:17:00 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-29 06:17:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-29 06:17:00 - TARGET=powerpc TB --- 2010-08-29 06:17:00 - TARGET_ARCH=powerpc64 TB --- 2010-08-29 06:17:00 - TZ=UTC TB --- 2010-08-29 06:17:00 - __MAKE_CONF=/dev/null TB --- 2010-08-29 06:17:00 - cd /src TB --- 2010-08-29 06:17:00 - /usr/bin/make -B buildworld World build started on Sun Aug 29 06:17:01 UTC 2010 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries [...] === gnu/lib/libgomp (all) cc -O2 -pipe -DHAVE_CONFIG_H -I/src/gnu/lib/libgomp -I. -I/src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp -I/src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/config/posix -std=gnu99 -fstack-protector -c /src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/alloc.c cc -O2 -pipe -DHAVE_CONFIG_H -I/src/gnu/lib/libgomp -I. -I/src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp -I/src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/config/posix -std=gnu99 -fstack-protector -c /src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/barrier.c cc -O2 -pipe -DHAVE_CONFIG_H -I/src/gnu/lib/libgomp -I. -I/src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp -I/src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/config/posix -std=gnu99 -fstack-protector -c /src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/critical.c cc -O2 -pipe -DHAVE_CONFIG_H -I/src/gnu/lib/libgomp -I. -I/src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp -I/src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/config/posix -std=gnu99 -fstack-protector -c /src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/env.c In file included from /src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/env.c:32: ./libgomp_f.h: In function 'omp_check_defines': ./libgomp_f.h:65: error: size of array 'test' is negative *** Error code 1 Stop in /src/gnu/lib/libgomp. *** Error code 1 Stop in /src/gnu/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-08-29 06:45:09 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-08-29 06:45:09 - ERROR: failed to build world TB --- 2010-08-29 06:45:09 - 1143.49 user 371.59 system 1742.83 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full ___ 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
patch for topology detection of Intel CPUs
[Reposted from stable@; edited] The below patch is against sources in FreeBSD tree, it should be applied either to sys/amd64/amd64/mp_machdep.c or sys/i386/i386/mp_machdep.c depending on the desired architecture: http://people.freebsd.org/~avg/intel-cpu-topo.diff The patch is substantially based on the Junk-uk's patch, but with some changes and additions: - topo_prob_0x4() is rewritten so that it does APIC ID matching against masks as described in the Intel article. The code still heavily depends on the assumption of the uniform topology, it discovers number of cores in BSP package and number of threads in BSP core and extrapolates that to global topology. The difference with current code and Junk-uk's patch is that actual APIC ID matching is done as opposed to deriving counts purely from max. values. - topo_prob_0x4() is invoked for 1 = cpu_high 4 case as well as for 4 = cpu_high 11 case as done in the current code, but unlike Junk-uk's patch. The code should be able to properly handle that class of CPUs and either detect hyperthreading topology or fallback to one processor per package topology. - added a few comments that describe uniformity assumption, plus couple other useful things. - changed final fallback code, so that each logical CPU is considered to be in its own physical package as opposed to current code placing all logical CPUs as cores of a single package. The rest is Junk-uk's work. Concerns: - about my code: ilog2_round_pow2 name is ugly; looking for suggestions on a better name or re-arranging/writing that code, so that the function is not needed. - about current code: logical_cpus variable (don't confuse with cpu_logical) doesn't seem to be consistently used; e.g. it is not set at all by topo_probo_0xb(); also, the method of using it for setting logical_cpus_mask doesn't seem to be reliable - BSP may be missed. Reviews, comments and test reports are very welcome! Please test the patch if you have any problems with how CPU topology is reported by the current code. Please test even if everything is OK, to avoid regressions. Thanks! -- Andriy Gapon ___ 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: [CFT] Improved ZFS metaslab code (faster write speed)
On 08/28/2010 05:26, Pawel Jakub Dawidek wrote:
On Sat, Aug 28, 2010 at 05:03:42AM -0400, jhell wrote:
On 08/28/2010 04:20, Andriy Gapon wrote:
on 28/08/2010 04:24 jhell said the following:
The modified patch from avg@ (portion patch) is:
#ifdef _KERNEL
if (arc_reclaim_needed()) {
needfree = 0;
wakeup(needfree);
}
#endif
I still moved that down to below _KERNEL for the obvious reasons. But
when I was using the original patch with if (needfree) I noticed a
performance degradation after ~12 hours of use with and without UMA
turned on. So far with ~48 hours of testing with the top half of that
being with the above change, I have not seen more degradation of
This is quite unexpected.
needfree should be checked as the very first thing in arc_reclaim_needed()
[unless you have patched it locally]. So if needfree is 1 then
arc_reclaim_needed() should also return 1. But the converse is not true,
arc_reclaim_needed() may return 1 even if needfree is zero.
So if your testing results are conclusive then it must mean that some extra
wakeups on needfree are needed. I.e. needfree is zero, so there shouldn't
be
anything waiting on it (see arc_lowmem) and no notification should be
needed,
but issuing somehow does make difference,
Hmm...
I will look further into this and see if I can throw a counter around it
or some printf's so I can at least log what its doing in both instances.
I thought the very same thing you said above when I saw your patch for
that and was astounded at the results that were returned from it. So in
short testing I reverted it back quickly to see if that was the cause of
the problem and sure enough everything resumed to the way it was before.
Anyway thanks for the reply. I will get back to you if I see anything
cool arise from this.
Could you include the following patch to your testing:
http://people.freebsd.org/~pjd/patches/arc.c.9.patch
Sure thing. Adding it now.
--
jhell,v
___
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: Difficulty playing DVDs under AHCI/CAM?
BTW, it seems that DVD burning with ahci is broken, burning a CD is okay, but I never burn a DVD sucessfully with ahci. Always get somethings like unable to wr...@60h input/output error and many (cd0:ahcich2:0:0:0): SCSI sense: ILLEGAL REQUEST csi:43,0,0,c asc:24,0 (Invalid field in CDB): Command byte 6 is invalid in dmesg, With ahci unloaded, I see (cd0:ata4:0:0:0): SCSI sense: ILLEGAL REQUEST csi:43,0,0,c asc:24,0 (Invalid field in CDB): Command byte 6 is invalid once, but it works. But I can read data DVD with ahci and sucessfully verify data with diff. --Buganini On Sat, Aug 28, 2010 at 5:41 PM, Garrett Wollman woll...@freebsd.org wrote: In article 4c79499b.3050...@icyb.net.ua a...@icyb.net.ua writes: [I wrote:] ...say what? Why is the cd driver suddenly returning ENXIO? Strange indeed. Can you dtrace this read? You can use combination of syscall and fbt providers with execname predicate. You're going to have to be much much more specific than that. -GAWollman ___ 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: Difficulty playing DVDs under AHCI/CAM?
On Sun, 29 Aug 2010 09:40:04 + Buganini bugan...@gmail.com wrote: BTW, it seems that DVD burning with ahci is broken, burning a CD is okay, but I never burn a DVD sucessfully with ahci. Always get somethings like unable to wr...@60h input/output error and many (cd0:ahcich2:0:0:0): SCSI sense: ILLEGAL REQUEST csi:43,0,0,c asc:24,0 (Invalid field in CDB): Command byte 6 is invalid in dmesg, With ahci unloaded, I see (cd0:ata4:0:0:0): SCSI sense: ILLEGAL REQUEST csi:43,0,0,c asc:24,0 (Invalid field in CDB): Command byte 6 is invalid once, but it works. But I can read data DVD with ahci and sucessfully verify data with diff. I've been using ahci for a long time (-current) and have absolutely no problem burning CDs/DVDs with xfburner. -- Gary Jennejohn ___ 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
One-shot-oriented event timers management
Hi. I would like to present my new work on timers management code. In my previous work I was mostly orienting on reimplementing existing functionality in better way. The result seemed not bad, but after looking on perspectives of using event timers in one-shot (aperiodic) mode I've understood that implemented code complexity made it hardly possible. So I had to significantly cut it down and rewrite from the new approach, which is instead primarily oriented on using timers in one-shot mode. As soon as some systems have only periodic timers I have left that functionality, though it was slightly limited. New management code implements two modes of operation: one-shot and periodic. Specific mode to be used depends on hardware capabilities and can be controlled. In one-shot mode hardware timers programmed to generate single interrupt precisely at the time of next wanted event. It is done by comparing current binuptime with next scheduled times of system events (hard-/stat-/profclock). This approach has several benefits: event timer precision is now irrelevant for system timekeeping, hard- and statclocks are not aliased, while only one timer used for it, and the most important -- it allows us to define which events and when exactly we really want to handle, without strict dependence on fixed hz, stathz, profhz periods. Sure, our callout system is highly depends on hz value, but now at least we can skip interrupts when we have no callouts to handle at the time. Later we can go further. Periodic mode now also uses alike principals of scheduling events. But timer running in periodic mode just unable to handle arbitrary events and as soon as event timers may not be synchronized to system timecounter and may drift from it, causing jitter effects. So I've used for time source of scheduling the timer events themselves. As result, periodic timer runs on fixed frequency multiply to hz rate, while statclock and profclock generated by dividing it respectively. (If somebody would tell me that hardclock jitter is not really a big problem, I would happily rip that artificial timekeeping out of there to simplify code.) Unluckily this approach makes impossible to use two events timers to completely separate hard- and statclocks any more, but as I have said, this mode is required only for limited set of systems without one-shot capable timers. Looking on my recent experience with different platforms, it is not a big fraction. Management code is still handles both per-CPU and global timers. Per-CPU timers usage is obvious. Global timer is programmed to handle all CPUs needs. In periodic mode global timer generates periodic interrupts to some one CPU, while management code then redistributes them to CPUs that really need it, using IPI. In one-shot mode timer is always programmed to handle first scheduled event throughout the system. When that interrupt arrives, it is also getting redistributed to wanting CPUs with IPI. To demonstrate features that could be obtained from so high flexibility I have incorporated the idea and some parts of dynamic ticks patches of Tsuyoshi Ozawa. Now, when some CPU goes down into C2/C3 ACPI sleep state, that CPU stops scheduling of hard-/stat-/profclock events until the next registered callout event. If CPU wakes up before that time by some unrelated interrupt, missed ticks are called artificially (it is needed now to keep realistic system stats). After system is up to date, interrupt is handled. Now it is implemented only for ACPI systems with C2/C3 states support, because ACPI resumes CPU with interrupts disabled, that allows to keep up missed time before interrupt handler or some other process (in case of unexpected task switch) may need it. As I can see, Linux does alike things in the beginning of every interrupt handler. 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! Here is the output of `systat -vm 1` from my test system: http://people.freebsd.org/~mav/systat_w_oneshot.txt . Obviously that with additional tuning the results can be improved even more. My latest patch against 9-CURRENT can be found here: http://people.freebsd.org/~mav/timers_oneshot4.patch Comments, ideas, propositions -- welcome! Thanks to all who read this. ;) -- Alexander Motin ___ 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
[head tinderbox] failure on powerpc64/powerpc
TB --- 2010-08-29 22:54:57 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-08-29 22:54:57 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2010-08-29 22:54:57 - cleaning the object tree TB --- 2010-08-29 22:55:09 - cvsupping the source tree TB --- 2010-08-29 22:55:09 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2010-08-29 22:55:37 - building world TB --- 2010-08-29 22:55:37 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-29 22:55:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-29 22:55:37 - TARGET=powerpc TB --- 2010-08-29 22:55:37 - TARGET_ARCH=powerpc64 TB --- 2010-08-29 22:55:37 - TZ=UTC TB --- 2010-08-29 22:55:37 - __MAKE_CONF=/dev/null TB --- 2010-08-29 22:55:37 - cd /src TB --- 2010-08-29 22:55:37 - /usr/bin/make -B buildworld World build started on Sun Aug 29 22:55:37 UTC 2010 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries [...] === gnu/lib/libgomp (all) cc -O2 -pipe -DHAVE_CONFIG_H -I/src/gnu/lib/libgomp -I. -I/src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp -I/src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/config/posix -std=gnu99 -fstack-protector -c /src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/alloc.c cc -O2 -pipe -DHAVE_CONFIG_H -I/src/gnu/lib/libgomp -I. -I/src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp -I/src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/config/posix -std=gnu99 -fstack-protector -c /src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/barrier.c cc -O2 -pipe -DHAVE_CONFIG_H -I/src/gnu/lib/libgomp -I. -I/src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp -I/src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/config/posix -std=gnu99 -fstack-protector -c /src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/critical.c cc -O2 -pipe -DHAVE_CONFIG_H -I/src/gnu/lib/libgomp -I. -I/src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp -I/src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/config/posix -std=gnu99 -fstack-protector -c /src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/env.c In file included from /src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/env.c:32: ./libgomp_f.h: In function 'omp_check_defines': ./libgomp_f.h:65: error: size of array 'test' is negative *** Error code 1 Stop in /src/gnu/lib/libgomp. *** Error code 1 Stop in /src/gnu/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-08-29 23:23:35 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-08-29 23:23:35 - ERROR: failed to build world TB --- 2010-08-29 23:23:35 - 1141.23 user 363.20 system 1718.73 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full ___ 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: [head tinderbox] failure on powerpc64/powerpc
On 08/29/10 18:23, FreeBSD Tinderbox wrote: TB --- 2010-08-29 22:54:57 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-08-29 22:54:57 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2010-08-29 22:54:57 - cleaning the object tree TB --- 2010-08-29 22:55:09 - cvsupping the source tree TB --- 2010-08-29 22:55:09 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2010-08-29 22:55:37 - building world TB --- 2010-08-29 22:55:37 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-29 22:55:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-29 22:55:37 - TARGET=powerpc TB --- 2010-08-29 22:55:37 - TARGET_ARCH=powerpc64 TB --- 2010-08-29 22:55:37 - TZ=UTC TB --- 2010-08-29 22:55:37 - __MAKE_CONF=/dev/null TB --- 2010-08-29 22:55:37 - cd /src TB --- 2010-08-29 22:55:37 - /usr/bin/make -B buildworld World build started on Sun Aug 29 22:55:37 UTC 2010 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries [...] === gnu/lib/libgomp (all) cc -O2 -pipe -DHAVE_CONFIG_H -I/src/gnu/lib/libgomp -I. -I/src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp -I/src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/config/posix -std=gnu99 -fstack-protector -c /src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/alloc.c cc -O2 -pipe -DHAVE_CONFIG_H -I/src/gnu/lib/libgomp -I. -I/src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp -I/src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/config/posix -std=gnu99 -fstack-protector -c /src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/barrier.c cc -O2 -pipe -DHAVE_CONFIG_H -I/src/gnu/lib/libgomp -I. -I/src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp -I/src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/config/posix -std=gnu99 -fstack-protector -c /src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/critical.c cc -O2 -pipe -DHAVE_CONFIG_H -I/src/gnu/lib/libgomp -I. -I/src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp -I/src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/config/posix -std=gnu99 -fstack-protector -c /src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/env.c In file included from /src/gnu/lib/libgomp/../../../contrib/gcclibs/libgomp/env.c:32: ./libgomp_f.h: In function 'omp_check_defines': ./libgomp_f.h:65: error: size of array 'test' is negative *** Error code 1 Is something wrong with cvsup? This bug was fixed two days ago in SVN. -Nathan ___ 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: [head tinderbox] failure on powerpc64/powerpc
At 07:29 PM 8/29/2010, Nathan Whitehorn wrote: Is something wrong with cvsup? This bug was fixed two days ago in SVN. Hi, There was a problem with the crontab entry on the local cvsup mirror that the tinder box syncs from for weekend runs / updates. I have fixed the ctab entry and kicked cvsup to start its updates now. ---Mike -Nathan ___ 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 Mike Tancsa, tel +1 519 651 3400 Sentex Communications,m...@sentex.net Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike ___ 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: [CFT] Improved ZFS metaslab code (faster write speed)
On Fri, 27 Aug 2010 20:34:18 -0700 Artem Belevich fbsdl...@src.cx wrote: Perhaps reduced UMA fragmentation helps those subsystem that do use UMA (including ZFS which always uses uma for various housekeeping data). PJD told me once that ZFS is always using UMA, it is just not using it for everything (except when the sysctl is switched to use it for everything). FYI: I have a 9-current system which panics (without a backtrace/dump) after 1-2 days of uptime when the zfs-uma-sysctl is activated. When it is not activated it survives several weeks (let's say about a month). So any work on the UMA fragmentation issue is well spend time. No, I haven't tested any of the patches on this machine. Bye, Alexander. ___ 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: One-shot-oriented event timers management
2010/8/29 Alexander Motin m...@freebsd.org:
Hi.
I would like to present my new work on timers management code.
In my previous work I was mostly orienting on reimplementing existing
functionality in better way. The result seemed not bad, but after
looking on perspectives of using event timers in one-shot (aperiodic)
mode I've understood that implemented code complexity made it hardly
possible. So I had to significantly cut it down and rewrite from the new
approach, which is instead primarily oriented on using timers in
one-shot mode. As soon as some systems have only periodic timers I have
left that functionality, though it was slightly limited.
New management code implements two modes of operation: one-shot and
periodic. Specific mode to be used depends on hardware capabilities and
can be controlled.
In one-shot mode hardware timers programmed to generate single interrupt
precisely at the time of next wanted event. It is done by comparing
current binuptime with next scheduled times of system events
(hard-/stat-/profclock). This approach has several benefits: event timer
precision is now irrelevant for system timekeeping, hard- and statclocks
are not aliased, while only one timer used for it, and the most
important -- it allows us to define which events and when exactly we
really want to handle, without strict dependence on fixed hz, stathz,
profhz periods. Sure, our callout system is highly depends on hz value,
but now at least we can skip interrupts when we have no callouts to
handle at the time. Later we can go further.
Periodic mode now also uses alike principals of scheduling events. But
timer running in periodic mode just unable to handle arbitrary events
and as soon as event timers may not be synchronized to system
timecounter and may drift from it, causing jitter effects. So I've used
for time source of scheduling the timer events themselves. As result,
periodic timer runs on fixed frequency multiply to hz rate, while
statclock and profclock generated by dividing it respectively. (If
somebody would tell me that hardclock jitter is not really a big
problem, I would happily rip that artificial timekeeping out of there to
simplify code.) Unluckily this approach makes impossible to use two
events timers to completely separate hard- and statclocks any more, but
as I have said, this mode is required only for limited set of systems
without one-shot capable timers. Looking on my recent experience with
different platforms, it is not a big fraction.
Management code is still handles both per-CPU and global timers. Per-CPU
timers usage is obvious. Global timer is programmed to handle all CPUs
needs. In periodic mode global timer generates periodic interrupts to
some one CPU, while management code then redistributes them to CPUs that
really need it, using IPI. In one-shot mode timer is always programmed
to handle first scheduled event throughout the system. When that
interrupt arrives, it is also getting redistributed to wanting CPUs with
IPI.
To demonstrate features that could be obtained from so high flexibility
I have incorporated the idea and some parts of dynamic ticks patches of
Tsuyoshi Ozawa. Now, when some CPU goes down into C2/C3 ACPI sleep
state, that CPU stops scheduling of hard-/stat-/profclock events until
the next registered callout event. If CPU wakes up before that time by
some unrelated interrupt, missed ticks are called artificially (it is
needed now to keep realistic system stats). After system is up to date,
interrupt is handled. Now it is implemented only for ACPI systems with
C2/C3 states support, because ACPI resumes CPU with interrupts disabled,
that allows to keep up missed time before interrupt handler or some
other process (in case of unexpected task switch) may need it. As I can
see, Linux does alike things in the beginning of every interrupt handler.
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! Here is the output of `systat -vm 1` from my test
system: http://people.freebsd.org/~mav/systat_w_oneshot.txt . Obviously
that with additional tuning the results can be improved even more.
My latest patch against 9-CURRENT can be found here:
http://people.freebsd.org/~mav/timers_oneshot4.patch
Comments, ideas, propositions -- welcome!
Thanks to all who read this. ;)
Totally awesome work m...@!
One thing I see:
Where is *frame pointing to? It isn't initialized in the function, so...
+static int
+handleevents(struct bintime *now, int fake)
{
+ struct
