Re: [RFC/RFT] calloutng
Experiments with dummynet shown ineffective support for very short tick-based callouts. New version fixes that, allowing to get as many tick-based callout events as hz value permits, while still be able to aggregate events and generating minimum of interrupts. Also this version modifies system load average calculation to fix some cases existing in HEAD and 9 branches, that could be fixed with new direct callout functionality. http://people.freebsd.org/~mav/calloutng_12_17.patch With several important changes made last time I am going to delay commit to HEAD for another week to do more testing. Comments and new test cases are welcome. Thanks for staying tuned and commenting. On 17.12.2012 01:37, Alexander Motin wrote: Here is one more version. Unless something new will be found/reported this may be the last one, because me and Davide are quite satisfied with the results. If everything will be fine, I think we could commit it to HEAD closer to the end of the week: http://people.freebsd.org/~mav/calloutng_12_16.patch Changes in this version: -- Removed couple of redundant variables in callout implementation, that reduced sizeof(struct callout) by two pointers and simplified some internal code. -- syscons driver was made to schedule only 1-2 callouts per second instead of 20-30 before when console is in graphical mode and there are few other things to do. Now my laptop has only about 30 interrupts per second total during idle periods with X running. -- i8254 eventtimer driver was optimized to work faster in disabled by default one-shot mode. -- Few kernel functions were added to make KPIs more complete. -- Man pages were updated. -- Some style fixes were made. On 15.12.2012 18:55, Alexander Motin wrote: I'm sorry to interrupt review, but as usual good ideas came during the final testing, causing another round. :) Here is updated patch for HEAD, that includes several new changes: http://people.freebsd.org/~mav/calloutng_12_15.patch The new changes are: -- Precision and event aggregation code was reworked. Instead of previous -prec/+prec representation, precision is now single-sided -- -0/+prec. It allowed to significantly improve precision on long time intervals for APIs which imply that event should not happen before the specified time. Depending on CPU activity, mistake for long time intervals now will never be more then 1-500ms, even if specified precision allows more. -- Some minor optimizations were made to reduce callout overhead and latency by 1.5-2us. Now on Core2Duo amd64 system with LAPIC eventtimer and TSC timecounter usleep(1) call from user-level executes in just 5-6us, instead of 7-8us before. Now it can do 180K cycles per second on single CPU with only partial CPU load. -- Number of kernel subsystems (dcons, syscons, yarrow, led, atkbd, setrlimit) were modified to reduce number of interrupts, also with event aggregation by explicit specification of the acceptable events precision. Now my Core2Duo test system has only 30 interrupts per second in idle. If not remaining syscons events, it could easily be 15. My IvyBridge ultrabook first time in its history shown 5.5 hours of battery time with full screen brightness and 10 hours with lid closed. -- Some kernel functions were added to make KPIs more complete. I've successfully tested this patch on amd64 and arm. -- 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 arm/arm
TB --- 2012-12-18 07:30:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-12-18 07:30:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-12-18 07:30:00 - starting HEAD tinderbox run for arm/arm TB --- 2012-12-18 07:30:00 - cleaning the object tree TB --- 2012-12-18 07:36:16 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-12-18 07:36:16 - cd /tinderbox/HEAD/arm/arm TB --- 2012-12-18 07:36:16 - /usr/local/bin/svn cleanup /src TB --- 2012-12-18 07:37:46 - /usr/local/bin/svn update /src TB --- 2012-12-18 07:38:04 - At svn revision 244385 TB --- 2012-12-18 07:38:05 - building world TB --- 2012-12-18 07:38:05 - CROSS_BUILD_TESTING=YES TB --- 2012-12-18 07:38:05 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-18 07:38:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-18 07:38:05 - SRCCONF=/dev/null TB --- 2012-12-18 07:38:05 - TARGET=arm TB --- 2012-12-18 07:38:05 - TARGET_ARCH=arm TB --- 2012-12-18 07:38:05 - TZ=UTC TB --- 2012-12-18 07:38:05 - __MAKE_CONF=/dev/null TB --- 2012-12-18 07:38:05 - cd /src TB --- 2012-12-18 07:38:05 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Tue Dec 18 07:38:11 UTC 2012 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 stage 4.3: make dependencies stage 4.4: building everything World build completed on Tue Dec 18 08:41:58 UTC 2012 TB --- 2012-12-18 08:41:58 - generating LINT kernel config TB --- 2012-12-18 08:41:58 - cd /src/sys/arm/conf TB --- 2012-12-18 08:41:58 - /usr/bin/make -B LINT TB --- 2012-12-18 08:41:58 - cd /src/sys/arm/conf TB --- 2012-12-18 08:41:58 - /usr/sbin/config -m LINT TB --- 2012-12-18 08:41:58 - building LINT kernel TB --- 2012-12-18 08:41:58 - CROSS_BUILD_TESTING=YES TB --- 2012-12-18 08:41:58 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-18 08:41:58 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-18 08:41:58 - SRCCONF=/dev/null TB --- 2012-12-18 08:41:58 - TARGET=arm TB --- 2012-12-18 08:41:58 - TARGET_ARCH=arm TB --- 2012-12-18 08:41:58 - TZ=UTC TB --- 2012-12-18 08:41:58 - __MAKE_CONF=/dev/null TB --- 2012-12-18 08:41:58 - cd /src TB --- 2012-12-18 08:41:58 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Tue Dec 18 08:41:58 UTC 2012 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT completed on Tue Dec 18 09:03:17 UTC 2012 TB --- 2012-12-18 09:03:17 - cd /src/sys/arm/conf TB --- 2012-12-18 09:03:17 - /usr/sbin/config -m AC100 TB --- 2012-12-18 09:03:17 - skipping AC100 kernel TB --- 2012-12-18 09:03:17 - cd /src/sys/arm/conf TB --- 2012-12-18 09:03:17 - /usr/sbin/config -m ARMADAXP TB --- 2012-12-18 09:03:17 - skipping ARMADAXP kernel TB --- 2012-12-18 09:03:17 - cd /src/sys/arm/conf TB --- 2012-12-18 09:03:17 - /usr/sbin/config -m ATMEL TB --- 2012-12-18 09:03:17 - building ATMEL kernel TB --- 2012-12-18 09:03:17 - CROSS_BUILD_TESTING=YES TB --- 2012-12-18 09:03:17 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-18 09:03:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-18 09:03:17 - SRCCONF=/dev/null TB --- 2012-12-18 09:03:17 - TARGET=arm TB --- 2012-12-18 09:03:17 - TARGET_ARCH=arm TB --- 2012-12-18 09:03:17 - TZ=UTC TB --- 2012-12-18 09:03:17 - __MAKE_CONF=/dev/null TB --- 2012-12-18 09:03:17 - cd /src TB --- 2012-12-18 09:03:17 - /usr/bin/make -B buildkernel KERNCONF=ATMEL Kernel build for ATMEL started on Tue Dec 18 09:03:18 UTC 2012 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for ATMEL completed on Tue Dec 18 09:07:33 UTC 2012 TB --- 2012-12-18 09:07:33 - cd /src/sys/arm/conf TB --- 2012-12-18 09:07:33 - /usr/sbin/config -m AVILA TB --- 2012-12-18 09:07:33 - skipping AVILA kernel TB --- 2012-12-18 09:07:33 - cd /src/sys/arm/conf TB --- 2012-12-18 09:07:33 - /usr/sbin/config -m BEAGLEBONE TB --- 2012-12-18 09:07:33 - skipping BEAGLEBONE kernel TB --- 2012-12-18 09:07:33 - cd /src/sys/arm/conf TB --- 2012-12-18 09:07:33 - /usr/sbin/config -m BWCT TB --- 2012-12-18 09:07:33 - building BWCT kernel TB --- 2012-12-18 09:07:33 - CROSS_BUILD_TESTING=YES TB --- 2012-12-18 09:07:33 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-18 09:07:33 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-18 09:07:33 - SRCCONF=/dev/null TB --- 2012-12-18 09:07:33 - TARGET=arm TB --- 2012-12-18 09:07:33 - TARGET_ARCH=arm TB --- 2012-12-18 09:07:33 -
Failed to initialize dwarf?
I checked out head Sunday and now my attempt at building a kernel says: ERROR: ctfconvert: failed to initialize DWARF: Unimplemented code at [dwarf_init_attr(400)] on every module it compiles (though it seems happy enough to keep compiling). Should I just ignore this?-- George Mitchell ___ 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: Failed to initialize dwarf?
On 2012-12-18 12:30, George Mitchell wrote: I checked out head Sunday and now my attempt at building a kernel says: ERROR: ctfconvert: failed to initialize DWARF: Unimplemented code at [dwarf_init_attr(400)] on every module it compiles (though it seems happy enough to keep compiling). Should I just ignore this?-- George Mitchell This problem was fixed in libdwarf in r239872; did you run make buildworld before make buildkernel? ___ 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 i386/i386
TB --- 2012-12-18 07:30:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-12-18 07:30:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-12-18 07:30:00 - starting HEAD tinderbox run for i386/i386 TB --- 2012-12-18 07:30:00 - cleaning the object tree TB --- 2012-12-18 07:40:33 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-12-18 07:40:33 - cd /tinderbox/HEAD/i386/i386 TB --- 2012-12-18 07:40:33 - /usr/local/bin/svn cleanup /src TB --- 2012-12-18 07:42:24 - /usr/local/bin/svn update /src TB --- 2012-12-18 07:42:33 - At svn revision 244385 TB --- 2012-12-18 07:42:34 - building world TB --- 2012-12-18 07:42:34 - CROSS_BUILD_TESTING=YES TB --- 2012-12-18 07:42:34 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-18 07:42:34 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-18 07:42:34 - SRCCONF=/dev/null TB --- 2012-12-18 07:42:34 - TARGET=i386 TB --- 2012-12-18 07:42:34 - TARGET_ARCH=i386 TB --- 2012-12-18 07:42:34 - TZ=UTC TB --- 2012-12-18 07:42:34 - __MAKE_CONF=/dev/null TB --- 2012-12-18 07:42:34 - cd /src TB --- 2012-12-18 07:42:34 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Tue Dec 18 07:42:40 UTC 2012 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 stage 4.3: make dependencies stage 4.4: building everything World build completed on Tue Dec 18 10:59:43 UTC 2012 TB --- 2012-12-18 10:59:43 - generating LINT kernel config TB --- 2012-12-18 10:59:43 - cd /src/sys/i386/conf TB --- 2012-12-18 10:59:43 - /usr/bin/make -B LINT TB --- 2012-12-18 10:59:43 - cd /src/sys/i386/conf TB --- 2012-12-18 10:59:43 - /usr/sbin/config -m LINT TB --- 2012-12-18 10:59:43 - building LINT kernel TB --- 2012-12-18 10:59:43 - CROSS_BUILD_TESTING=YES TB --- 2012-12-18 10:59:43 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-18 10:59:43 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-18 10:59:43 - SRCCONF=/dev/null TB --- 2012-12-18 10:59:43 - TARGET=i386 TB --- 2012-12-18 10:59:43 - TARGET_ARCH=i386 TB --- 2012-12-18 10:59:43 - TZ=UTC TB --- 2012-12-18 10:59:43 - __MAKE_CONF=/dev/null TB --- 2012-12-18 10:59:43 - cd /src TB --- 2012-12-18 10:59:43 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Tue Dec 18 10:59:43 UTC 2012 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT completed on Tue Dec 18 11:32:41 UTC 2012 TB --- 2012-12-18 11:32:41 - cd /src/sys/i386/conf TB --- 2012-12-18 11:32:41 - /usr/sbin/config -m LINT-NOINET TB --- 2012-12-18 11:32:41 - building LINT-NOINET kernel TB --- 2012-12-18 11:32:41 - CROSS_BUILD_TESTING=YES TB --- 2012-12-18 11:32:41 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-18 11:32:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-18 11:32:41 - SRCCONF=/dev/null TB --- 2012-12-18 11:32:41 - TARGET=i386 TB --- 2012-12-18 11:32:41 - TARGET_ARCH=i386 TB --- 2012-12-18 11:32:41 - TZ=UTC TB --- 2012-12-18 11:32:41 - __MAKE_CONF=/dev/null TB --- 2012-12-18 11:32:41 - cd /src TB --- 2012-12-18 11:32:41 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET Kernel build for LINT-NOINET started on Tue Dec 18 11:32:41 UTC 2012 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT-NOINET completed on Tue Dec 18 12:03:32 UTC 2012 TB --- 2012-12-18 12:03:32 - cd /src/sys/i386/conf TB --- 2012-12-18 12:03:32 - /usr/sbin/config -m LINT-NOINET6 TB --- 2012-12-18 12:03:32 - building LINT-NOINET6 kernel TB --- 2012-12-18 12:03:32 - CROSS_BUILD_TESTING=YES TB --- 2012-12-18 12:03:32 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-18 12:03:32 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-18 12:03:32 - SRCCONF=/dev/null TB --- 2012-12-18 12:03:32 - TARGET=i386 TB --- 2012-12-18 12:03:32 - TARGET_ARCH=i386 TB --- 2012-12-18 12:03:32 - TZ=UTC TB --- 2012-12-18 12:03:32 - __MAKE_CONF=/dev/null TB --- 2012-12-18 12:03:32 - cd /src TB --- 2012-12-18 12:03:32 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 Kernel build for LINT-NOINET6 started on Tue Dec 18 12:03:33 UTC 2012 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes
protoc crash in libstdc++
Hi,
the following backtrace is from a crash that happened when building
www/chromium with clang. The chromium port builds a binary protoc which
crashes when built with clang.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 802006400 (LWP 100869)]
0x000800996506 in std::ostream::sentry::sentry(std::ostream) ()
from /usr/lib/libstdc++.so.6
(gdb) bt
#0 0x000800996506 in std::ostream::sentry::sentry(std::ostream) ()
from /usr/lib/libstdc++.so.6
#1 0x0008009964cd in std::basic_ostreamchar::sentry::sentry
(this=0x7fffcf88, __os=...) at /usr/include/c++/4.2/ostream:62
#2 0x000800998a4b in std::__ostream_insertchar,
std::char_traitschar (__out=..., __s=0x485df0 Missing input file.,
__n=19)
at
/usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/include/bits/ostream_insert.h:83
#3 0x0040592c in operatorstd::char_traitschar
(this=optimized out, __out=..., __out=..., __s=optimized out) at
/usr/include/c++/4.2/ostream:517
#4 google::protobuf::compiler::CommandLineInterface::ParseArguments
(this=optimized out, argc=1, argv=0x7fffd640) at
third_party/protobuf/src/google/protobuf/compiler/command_line_interface.cc:790
#5 0x004048b0 in
google::protobuf::compiler::CommandLineInterface::Run
(this=0x7fffd4d0, argc=-12408, argv=0x7fffcf88)
at
third_party/protobuf/src/google/protobuf/compiler/command_line_interface.cc:588
#6 0x00432957 in main (argc=-12408, argv=0x7fffcf88) at
third_party/protobuf/src/google/protobuf/compiler/main.cc:59
(gdb) frame 2
#2 0x000800998a4b in std::__ostream_insertchar,
std::char_traitschar (__out=..., __s=0x485df0 Missing input file.,
__n=19)
at
/usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/include/bits/ostream_insert.h:83
83
(gdb) list
78 __ostream_insert(basic_ostream_CharT, _Traits __out,
79 const _CharT* __s, streamsize __n)
80 {
81typedef basic_ostream_CharT, _Traits __ostream_type;
82typedef typename __ostream_type::ios_base__ios_base;
83
84typename __ostream_type::sentry __cerb(__out);
...
So the question is if this is a protoc or a clang or a libstdc++ bug.
René
___
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: regarding r242905 ('us' argument to some callout functions) was Re: [RFC/RFT] calloutng
On Mon, Dec 17, 2012 at 01:22:59PM -0800, Adrian Chadd wrote: Personally, I'd rather see some consistently used units here.. bintime (or something similar) is the correct choice here. If we are concerned about the size (128 bit) then we can map it to a shorter, fixed point format, such as sign+31+32 as phk was suggesting. cheers luigi ___ 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: protoc crash in libstdc++
On Tue, Dec 18, 2012 at 01:21:42PM +0100, Ren? Ladan wrote: Hi, the following backtrace is from a crash that happened when building www/chromium with clang. The chromium port builds a binary protoc which crashes when built with clang. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 802006400 (LWP 100869)] 0x000800996506 in std::ostream::sentry::sentry(std::ostream) () from /usr/lib/libstdc++.so.6 (gdb) bt #0 0x000800996506 in std::ostream::sentry::sentry(std::ostream) () from /usr/lib/libstdc++.so.6 #1 0x0008009964cd in std::basic_ostreamchar::sentry::sentry (this=0x7fffcf88, __os=...) at /usr/include/c++/4.2/ostream:62 #2 0x000800998a4b in std::__ostream_insertchar, std::char_traitschar (__out=..., __s=0x485df0 Missing input file., __n=19) at /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/include/bits/ostream_insert.h:83 #3 0x0040592c in operatorstd::char_traitschar (this=optimized out, __out=..., __out=..., __s=optimized out) at /usr/include/c++/4.2/ostream:517 #4 google::protobuf::compiler::CommandLineInterface::ParseArguments (this=optimized out, argc=1, argv=0x7fffd640) at third_party/protobuf/src/google/protobuf/compiler/command_line_interface.cc:790 #5 0x004048b0 in google::protobuf::compiler::CommandLineInterface::Run (this=0x7fffd4d0, argc=-12408, argv=0x7fffcf88) at third_party/protobuf/src/google/protobuf/compiler/command_line_interface.cc:588 #6 0x00432957 in main (argc=-12408, argv=0x7fffcf88) at ^^ wow :) Can you run this under valgrind? Roman ___ 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 amd64/amd64
TB --- 2012-12-18 07:30:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-12-18 07:30:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-12-18 07:30:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2012-12-18 07:30:00 - cleaning the object tree TB --- 2012-12-18 07:42:39 - checking out /src from svn://svn.freebsd.org/base/head TB --- 2012-12-18 07:42:39 - cd /tinderbox/HEAD/amd64/amd64 TB --- 2012-12-18 07:42:39 - /usr/local/bin/svn cleanup /src TB --- 2012-12-18 07:44:55 - /usr/local/bin/svn update /src TB --- 2012-12-18 07:45:02 - At svn revision 244385 TB --- 2012-12-18 07:45:03 - building world TB --- 2012-12-18 07:45:03 - CROSS_BUILD_TESTING=YES TB --- 2012-12-18 07:45:03 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-18 07:45:03 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-18 07:45:03 - SRCCONF=/dev/null TB --- 2012-12-18 07:45:03 - TARGET=amd64 TB --- 2012-12-18 07:45:03 - TARGET_ARCH=amd64 TB --- 2012-12-18 07:45:03 - TZ=UTC TB --- 2012-12-18 07:45:03 - __MAKE_CONF=/dev/null TB --- 2012-12-18 07:45:03 - cd /src TB --- 2012-12-18 07:45:03 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Tue Dec 18 07:45:08 UTC 2012 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 stage 4.3: make dependencies stage 4.4: building everything stage 5.1: building 32 bit shim libraries World build completed on Tue Dec 18 11:38:40 UTC 2012 TB --- 2012-12-18 11:38:40 - generating LINT kernel config TB --- 2012-12-18 11:38:40 - cd /src/sys/amd64/conf TB --- 2012-12-18 11:38:40 - /usr/bin/make -B LINT TB --- 2012-12-18 11:38:41 - cd /src/sys/amd64/conf TB --- 2012-12-18 11:38:41 - /usr/sbin/config -m LINT TB --- 2012-12-18 11:38:41 - building LINT kernel TB --- 2012-12-18 11:38:41 - CROSS_BUILD_TESTING=YES TB --- 2012-12-18 11:38:41 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-18 11:38:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-18 11:38:41 - SRCCONF=/dev/null TB --- 2012-12-18 11:38:41 - TARGET=amd64 TB --- 2012-12-18 11:38:41 - TARGET_ARCH=amd64 TB --- 2012-12-18 11:38:41 - TZ=UTC TB --- 2012-12-18 11:38:41 - __MAKE_CONF=/dev/null TB --- 2012-12-18 11:38:41 - cd /src TB --- 2012-12-18 11:38:41 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Tue Dec 18 11:38:41 UTC 2012 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT completed on Tue Dec 18 12:12:17 UTC 2012 TB --- 2012-12-18 12:12:17 - cd /src/sys/amd64/conf TB --- 2012-12-18 12:12:17 - /usr/sbin/config -m LINT-NOINET TB --- 2012-12-18 12:12:17 - building LINT-NOINET kernel TB --- 2012-12-18 12:12:17 - CROSS_BUILD_TESTING=YES TB --- 2012-12-18 12:12:17 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-18 12:12:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-18 12:12:17 - SRCCONF=/dev/null TB --- 2012-12-18 12:12:17 - TARGET=amd64 TB --- 2012-12-18 12:12:17 - TARGET_ARCH=amd64 TB --- 2012-12-18 12:12:17 - TZ=UTC TB --- 2012-12-18 12:12:17 - __MAKE_CONF=/dev/null TB --- 2012-12-18 12:12:17 - cd /src TB --- 2012-12-18 12:12:17 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET Kernel build for LINT-NOINET started on Tue Dec 18 12:12:17 UTC 2012 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT-NOINET completed on Tue Dec 18 12:42:59 UTC 2012 TB --- 2012-12-18 12:42:59 - cd /src/sys/amd64/conf TB --- 2012-12-18 12:42:59 - /usr/sbin/config -m LINT-NOINET6 TB --- 2012-12-18 12:42:59 - building LINT-NOINET6 kernel TB --- 2012-12-18 12:42:59 - CROSS_BUILD_TESTING=YES TB --- 2012-12-18 12:42:59 - MAKEOBJDIRPREFIX=/obj TB --- 2012-12-18 12:42:59 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-12-18 12:42:59 - SRCCONF=/dev/null TB --- 2012-12-18 12:42:59 - TARGET=amd64 TB --- 2012-12-18 12:42:59 - TARGET_ARCH=amd64 TB --- 2012-12-18 12:42:59 - TZ=UTC TB --- 2012-12-18 12:42:59 - __MAKE_CONF=/dev/null TB --- 2012-12-18 12:42:59 - cd /src TB --- 2012-12-18 12:42:59 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 Kernel build for LINT-NOINET6 started on Tue Dec 18 12:42:59 UTC 2012 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls
Re: API explosion (Re: [RFC/RFT] calloutng)
On Mon, Dec 17, 2012 at 11:03:53PM +0200, Alexander Motin wrote: Hi. I would instead do the following: I also don't very like the wide API and want to hear fresh ideas, but approaches to time measurement there are too different to do what you are proposing. Main problem is that while ticks value is relative, bintime is absolute. It is not easy to make conversion between them fast and precise. I've managed to do it, but the only function that does it now is _callout_reset_on(). All other functions are just passing values down. I am not sure I want to duplicate that code in each place, though doing it at least for for callout may be a good idea. I am afraid the above is not convincing. Most/all of the APIs i mentioned still have the conversion from ticks to bintime, and the code in your patch is just building multiple parallel paths (one for each of the three versions of the same function) to some final piece of code where the conversion takes place. The problem is that all of this goes through a set of obfuscating macros and the end result is horrible. To be clear, i believe the work you have been doing on cleaning up callout is great, i am just saying that this is the time to look at the code from a few steps away and clean up all those design decisions that perhaps were made in a haste to make things work. I will give you another example to show how convoluted is the code now: cv_timedwait() and cv_timedwait_sig() now have three versions each (plain, bt, flags). These six are remapped through macros to two functions, _cv_timedwait() and _cv_timedwait_sig(), with a possible bug (cv_timedwait_bt() maps to _cv_timedwait_sig() ) These two _cv_timedwait*() take both ticks and bintimes, and contain this sequence: + if (bt == NULL) + sleepq_set_timeout_flags(cvp, timo, flags); + else + sleepq_set_timeout_bt(cvp, bt, precision); Guess what, both sleepq_* are macros that remap to the same _sleepq_set_timeout(...) . So the above if (bt == NULL) is useless. But then if you dig into _sleepq_set_timeout() you'll see + if (bt == NULL) + callout_reset_flags_on(td-td_slpcallout, timo, + sleepq_timeout, td, PCPU_GET(cpuid), flags | C_DIRECT_EXEC); + else + callout_reset_bt_on(td-td_slpcallout, bt, precision, + sleepq_timeout, td, PCPU_GET(cpuid), flags | C_DIRECT_EXEC); and again both callout_reset*() are again remapped through macros to _callout_reset_on(), so another useless if (bt == NULL) And in the end you have the conversion from ticks to bintime. So basically the code path for cv_timedwait() has those two useless switches and one useless extra argument, and the conversion from ticks to bintime is down deep down in _callout_reset_on() where it can only be resolved at runtime, whereas by doing the conversion at the beginning the decision could have been made at compile time. So I believe my proposal would give large simplifications in the code and lead to a much cleaner implementation of what you have designed: 1. acknowledge the fact that the only representation of time that callouts use internally is a bintime+precision, define one single function (instead of two or three or six) that implements the blessed API, and implement the others with macros or inline functions doing the appropriate conversions; 2. specifically, the *_flags() variant has no reason to exist. It can be implemented through the *_bt() variant, and being a new function the only places where you introduce it require manual modifications so you can directly invoke the new function. Again, please take this as constructive criticism, as i really like the work you have been doing and appreciate the time and effort you are putting on it cheers luigi Creating sets of three functions I had three different goals: - callout_reset() -- it is legacy variant required to keep API compatibility; - callout_reset_flags() -- it is for cases where custom precision specification needs to be added to the existing code, or where direct callout execution is needed. Conversion to bintime would additionally complicate consumer code, that I would try to avoid. - callout_reset_bt() -- API for the new code, which needs high precision and doesn't mind to operate bintime. Now there is only three such places in kernel now, and I don't think there will be much more. Respectively, these three options are replicated to other APIs where time intervals are used. PS: Please keep me in CC. -- 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
Re: API explosion (Re: [RFC/RFT] calloutng)
On Tue, Dec 18, 2012 at 06:36:43PM +0100, Luigi Rizzo wrote: On Mon, Dec 17, 2012 at 11:03:53PM +0200, Alexander Motin wrote: ... So I believe my proposal would give large simplifications in the code and lead to a much cleaner implementation of what you have designed: 1. acknowledge the fact that the only representation of time that callouts use internally is a bintime+precision, define one single function (instead of two or three or six) that implements the blessed API, and implement the others with macros or inline functions doing the appropriate conversions; 2. specifically, the *_flags() variant has no reason to exist. It can be implemented through the *_bt() variant, and being a new function the only places where you introduce it require manual modifications so you can directly invoke the new function. to clarify: i am not sure if now the *_bt() variant takes flags too, but my point is that the main API function should take all supported arguments (including flags) and others should simply be regarded as simplified versions. More or less what we have for sockets, with send() and sendmsg() and friend cheers luigi ___ 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: API explosion (Re: [RFC/RFT] calloutng)
On 18.12.2012 19:36, Luigi Rizzo wrote: On Mon, Dec 17, 2012 at 11:03:53PM +0200, Alexander Motin wrote: I would instead do the following: I also don't very like the wide API and want to hear fresh ideas, but approaches to time measurement there are too different to do what you are proposing. Main problem is that while ticks value is relative, bintime is absolute. It is not easy to make conversion between them fast and precise. I've managed to do it, but the only function that does it now is _callout_reset_on(). All other functions are just passing values down. I am not sure I want to duplicate that code in each place, though doing it at least for for callout may be a good idea. I am afraid the above is not convincing. Most/all of the APIs i mentioned still have the conversion from ticks to bintime, and the code in your patch is just building multiple parallel paths (one for each of the three versions of the same function) to some final piece of code where the conversion takes place. The problem is that all of this goes through a set of obfuscating macros and the end result is horrible. To be clear, i believe the work you have been doing on cleaning up callout is great, i am just saying that this is the time to look at the code from a few steps away and clean up all those design decisions that perhaps were made in a haste to make things work. I will give you another example to show how convoluted is the code now: cv_timedwait() and cv_timedwait_sig() now have three versions each (plain, bt, flags). These six are remapped through macros to two functions, _cv_timedwait() and _cv_timedwait_sig(), with a possible bug (cv_timedwait_bt() maps to _cv_timedwait_sig() ) These two _cv_timedwait*() take both ticks and bintimes, and contain this sequence: + if (bt == NULL) + sleepq_set_timeout_flags(cvp, timo, flags); + else + sleepq_set_timeout_bt(cvp, bt, precision); Guess what, both sleepq_* are macros that remap to the same _sleepq_set_timeout(...) . So the above if (bt == NULL) is useless. But then if you dig into _sleepq_set_timeout() you'll see + if (bt == NULL) + callout_reset_flags_on(td-td_slpcallout, timo, + sleepq_timeout, td, PCPU_GET(cpuid), flags | C_DIRECT_EXEC); + else + callout_reset_bt_on(td-td_slpcallout, bt, precision, + sleepq_timeout, td, PCPU_GET(cpuid), flags | C_DIRECT_EXEC); and again both callout_reset*() are again remapped through macros to _callout_reset_on(), so another useless if (bt == NULL) And in the end you have the conversion from ticks to bintime. So basically the code path for cv_timedwait() has those two useless switches and one useless extra argument, and the conversion from ticks to bintime is down deep down in _callout_reset_on() where it can only be resolved at runtime, whereas by doing the conversion at the beginning the decision could have been made at compile time. So I believe my proposal would give large simplifications in the code and lead to a much cleaner implementation of what you have designed: 1. acknowledge the fact that the only representation of time that callouts use internally is a bintime+precision, define one single function (instead of two or three or six) that implements the blessed API, and implement the others with macros or inline functions doing the appropriate conversions; 2. specifically, the *_flags() variant has no reason to exist. It can be implemented through the *_bt() variant, and being a new function the only places where you introduce it require manual modifications so you can directly invoke the new function. Again, please take this as constructive criticism, as i really like the work you have been doing and appreciate the time and effort you are putting on it Your words about useless cascaded ifs touched me. Actually I've looked on _callout_reset_bt_on() yesterday, thinking about moving tick to bt conversion to separate function or wrapper. The only thing we would save in such case is single integer argument (ticks), as all others (bt, prec, flags) are used in the new world order. From the other side, to make the conversion process really effective and correct, I've used quite specific way of obtaining time, that may change in the future. I would not really like it to be inlined in every consumer function and become an ABI. So I see two possible ways: make that conversion a separate non-inline function (that will require two temporary variables to return results and will consume some time on call/return), or make callout_reset_bt_on() to have extra ticks argument, allowing to use it in one or another way without external ifs and macros. In last case all _bt functions in other APIs will also obtain ticks, bt, pr and flags arguments. Actually flags there could be used to specify time scale (monotonic or wall) and time base (relative or absolute), if we
Re: protoc crash in libstdc++
==90885== Memcheck, a memory error detector ==90885== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==90885== Using Valgrind-3.8.0 and LibVEX; rerun with -h for copyright info ==90885== Command: ./protoc ==90885== ==90885== Invalid read of size 8 ==90885==at 0x1388506: std::ostream::sentry::sentry(std::ostream) (ostream.tcc:55) ==90885==by 0x13884CC: std::ostream::sentry::sentry(std::ostream) (ostream:62) ==90885==by 0x138AA4A: std::basic_ostreamchar, std::char_traitschar std::__ostream_insertchar, std::char_traitschar (std::basic_ostreamchar, std::char_traitschar , char const*, long) (ostream_insert.h:83) ==90885==by 0x40599B: google::protobuf::compiler::CommandLineInterface::ParseArguments(int, char const* const*) (ostream:517) ==90885==by 0x40491F: google::protobuf::compiler::CommandLineInterface::Run(int, char const* const*) (command_line_interface.cc:588) ==90885==by 0x4329D0: main (main.cc:63) ==90885== Address 0xffe8 is not stack'd, malloc'd or (recently) free'd ==90885== ==90885== ==90885== Process terminating with default action of signal 11 (SIGSEGV): dumping core ==90885== Access not within mapped region at address 0xFFE8 ==90885==at 0x1388506: std::ostream::sentry::sentry(std::ostream) (ostream.tcc:55) ==90885==by 0x13884CC: std::ostream::sentry::sentry(std::ostream) (ostream:62) ==90885==by 0x138AA4A: std::basic_ostreamchar, std::char_traitschar std::__ostream_insertchar, std::char_traitschar (std::basic_ostreamchar, std::char_traitschar , char const*, long) (ostream_insert.h:83) ==90885==by 0x40599B: google::protobuf::compiler::CommandLineInterface::ParseArguments(int, char const* const*) (ostream:517) ==90885==by 0x40491F: google::protobuf::compiler::CommandLineInterface::Run(int, char const* const*) (command_line_interface.cc:588) ==90885==by 0x4329D0: main (main.cc:63) ==90885== If you believe this happened as a result of a stack ==90885== overflow in your program's main thread (unlikely but ==90885== possible), you can try to increase the size of the ==90885== main thread stack using the --main-stacksize= flag. ==90885== The main thread stack size used in this run was 16777216. ==90885== ==90885== HEAP SUMMARY: ==90885== in use at exit: 1,949 bytes in 20 blocks ==90885== total heap usage: 20 allocs, 0 frees, 1,949 bytes allocated ==90885== ==90885== 26 bytes in 1 blocks are possibly lost in loss record 3 of 20 ==90885==at 0x10BBFB6: malloc (in /usr/local/lib/valgrind/vgpreload_memcheck-amd64-freebsd.so) ==90885==by 0x1FD595A: operator new(unsigned long) (in /usr/lib/libsupc++.so.1) ==90885==by 0x1375465: __gnu_cxx::new_allocatorchar::allocate(unsigned long, void const*) (new_allocator.h:91) ==90885==by 0x1375373: std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocatorchar const) (basic_string.tcc:588) ==90885==by 0x137A8AF: char* std::string::_S_constructchar const*(char const*, char const*, std::allocatorchar const, std::forward_iterator_tag) (basic_string.tcc:150) ==90885==by 0x137AB34: char* std::string::_S_construct_auxchar const*(char const*, char const*, std::allocatorchar const, std::__false_type) (basic_string.h:1453) ==90885==by 0x1376644: char* std::string::_S_constructchar const*(char const*, char const*, std::allocatorchar const) (basic_string.h:1468) ==90885==by 0x13766F4: std::basic_stringchar, std::char_traitschar, std::allocatorchar ::basic_string(char const*, std::allocatorchar const) (basic_string.h:226) ==90885==by 0x1376674: std::basic_stringchar, std::char_traitschar, std::allocatorchar ::basic_string(char const*, std::allocatorchar const) (basic_string.h:228) ==90885==by 0x4057CF: google::protobuf::compiler::CommandLineInterface::ParseArguments(int, char const* const*) (command_line_interface.cc:784) ==90885==by 0x40491F: google::protobuf::compiler::CommandLineInterface::Run(int, char const* const*) (command_line_interface.cc:588) ==90885==by 0x4329D0: main (main.cc:63) ==90885== ==90885== 32 bytes in 1 blocks are possibly lost in loss record 4 of 20 ==90885==at 0x10BBFB6: malloc (in /usr/local/lib/valgrind/vgpreload_memcheck-amd64-freebsd.so) ==90885==by 0x1FD595A: operator new(unsigned long) (in /usr/lib/libsupc++.so.1) ==90885==by 0x1375465: __gnu_cxx::new_allocatorchar::allocate(unsigned long, void const*) (new_allocator.h:91) ==90885==by 0x1375373: std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocatorchar const) (basic_string.tcc:588) ==90885==by 0x137A8AF: char* std::string::_S_constructchar const*(char const*, char const*, std::allocatorchar const, std::forward_iterator_tag) (basic_string.tcc:150) ==90885==by 0x137AB34: char* std::string::_S_construct_auxchar const*(char const*, char const*, std::allocatorchar const, std::__false_type) (basic_string.h:1453) ==90885==by 0x1376644: char* std::string::_S_constructchar const*(char const*, char
Re: protoc crash in libstdc++
On 2012-12-18 13:21, René Ladan wrote: the following backtrace is from a crash that happened when building www/chromium with clang. The chromium port builds a binary protoc which crashes when built with clang. ... So the question is if this is a protoc or a clang or a libstdc++ bug. Try removing --gc-sections from the link flags for protoc, that should solve it for now. I am still looking at the root cause, which seems to be something in our ld; it does not seem to be related to either clang or libstdc++. ___ 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: protoc crash in libstdc++
Try removing --gc-sections from the link flags for protoc, that should solve it for now. I am still looking at the root cause, which seems to be something in our ld; it does not seem to be related to either clang or libstdc++. Whoa, thank you! Removing --gc-sections from the link flags solves the issue indeed! ___ 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: Failed to initialize dwarf?
I have a checkout of r244047. I did a make kernel-toolchain followed by a make buildkernel and I see this warning. On Tue, Dec 18, 2012 at 7:15 AM, Dimitry Andric d...@freebsd.org wrote: On 2012-12-18 12:30, George Mitchell wrote: I checked out head Sunday and now my attempt at building a kernel says: ERROR: ctfconvert: failed to initialize DWARF: Unimplemented code at [dwarf_init_attr(400)] on every module it compiles (though it seems happy enough to keep compiling). Should I just ignore this?-- George Mitchell This problem was fixed in libdwarf in r239872; did you run make buildworld before make buildkernel? __**_ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/**mailman/listinfo/freebsd-**currenthttp://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscribe@** freebsd.org 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: API explosion (Re: [RFC/RFT] calloutng)
On 18.12.2012 20:03, Alexander Motin wrote: On 18.12.2012 19:36, Luigi Rizzo wrote: On Mon, Dec 17, 2012 at 11:03:53PM +0200, Alexander Motin wrote: I would instead do the following: I also don't very like the wide API and want to hear fresh ideas, but approaches to time measurement there are too different to do what you are proposing. Main problem is that while ticks value is relative, bintime is absolute. It is not easy to make conversion between them fast and precise. I've managed to do it, but the only function that does it now is _callout_reset_on(). All other functions are just passing values down. I am not sure I want to duplicate that code in each place, though doing it at least for for callout may be a good idea. I am afraid the above is not convincing. Most/all of the APIs i mentioned still have the conversion from ticks to bintime, and the code in your patch is just building multiple parallel paths (one for each of the three versions of the same function) to some final piece of code where the conversion takes place. The problem is that all of this goes through a set of obfuscating macros and the end result is horrible. To be clear, i believe the work you have been doing on cleaning up callout is great, i am just saying that this is the time to look at the code from a few steps away and clean up all those design decisions that perhaps were made in a haste to make things work. I will give you another example to show how convoluted is the code now: cv_timedwait() and cv_timedwait_sig() now have three versions each (plain, bt, flags). These six are remapped through macros to two functions, _cv_timedwait() and _cv_timedwait_sig(), with a possible bug (cv_timedwait_bt() maps to _cv_timedwait_sig() ) These two _cv_timedwait*() take both ticks and bintimes, and contain this sequence: +if (bt == NULL) +sleepq_set_timeout_flags(cvp, timo, flags); +else +sleepq_set_timeout_bt(cvp, bt, precision); Guess what, both sleepq_* are macros that remap to the same _sleepq_set_timeout(...) . So the above if (bt == NULL) is useless. But then if you dig into _sleepq_set_timeout() you'll see +if (bt == NULL) +callout_reset_flags_on(td-td_slpcallout, timo, +sleepq_timeout, td, PCPU_GET(cpuid), flags | C_DIRECT_EXEC); +else +callout_reset_bt_on(td-td_slpcallout, bt, precision, +sleepq_timeout, td, PCPU_GET(cpuid), flags | C_DIRECT_EXEC); and again both callout_reset*() are again remapped through macros to _callout_reset_on(), so another useless if (bt == NULL) And in the end you have the conversion from ticks to bintime. So basically the code path for cv_timedwait() has those two useless switches and one useless extra argument, and the conversion from ticks to bintime is down deep down in _callout_reset_on() where it can only be resolved at runtime, whereas by doing the conversion at the beginning the decision could have been made at compile time. So I believe my proposal would give large simplifications in the code and lead to a much cleaner implementation of what you have designed: 1. acknowledge the fact that the only representation of time that callouts use internally is a bintime+precision, define one single function (instead of two or three or six) that implements the blessed API, and implement the others with macros or inline functions doing the appropriate conversions; 2. specifically, the *_flags() variant has no reason to exist. It can be implemented through the *_bt() variant, and being a new function the only places where you introduce it require manual modifications so you can directly invoke the new function. Again, please take this as constructive criticism, as i really like the work you have been doing and appreciate the time and effort you are putting on it Your words about useless cascaded ifs touched me. Actually I've looked on _callout_reset_bt_on() yesterday, thinking about moving tick to bt conversion to separate function or wrapper. The only thing we would save in such case is single integer argument (ticks), as all others (bt, prec, flags) are used in the new world order. From the other side, to make the conversion process really effective and correct, I've used quite specific way of obtaining time, that may change in the future. I would not really like it to be inlined in every consumer function and become an ABI. So I see two possible ways: make that conversion a separate non-inline function (that will require two temporary variables to return results and will consume some time on call/return), or make callout_reset_bt_on() to have extra ticks argument, allowing to use it in one or another way without external ifs and macros. In last case all _bt functions in other APIs will also obtain ticks, bt, pr and flags arguments. Actually flags there could be used to specify time scale (monotonic or wall) and time base (relative or absolute), if we decide to implement all
Re: Failed to initialize dwarf?
On 2012-12-18 22:37, Ryan Stone wrote: On Tue, Dec 18, 2012 at 7:15 AM, Dimitry Andric d...@freebsd.org mailto:d...@freebsd.org wrote: On 2012-12-18 12:30, George Mitchell wrote: ERROR: ctfconvert: failed to initialize DWARF: Unimplemented code at [dwarf_init_attr(400)] This problem was fixed in libdwarf in r239872; did you run make buildworld before make buildkernel? I have a checkout of r244047. I did a make kernel-toolchain followed by a make buildkernel and I see this warning. The question is if ctfconvert (and dependencies) are rebuilt when you do kernel-toolchain. Can you figure out if it runs ctfconvert from base? ___ 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: Failed to initialize dwarf?
On Tue, Dec 18, 2012 at 4:56 PM, Dimitry Andric d...@freebsd.org wrote:
The question is if ctfconvert (and dependencies) are rebuilt when you do
kernel-toolchain. Can you figure out if it runs ctfconvert from base?
Aha! You're right:
[rstone@rstone-laptop vll]make buildenv
Entering world for amd64:amd64
$ which ctfconvert
/usr/bin/ctfconvert
$ which cc
/home/rstone/obj/usr/home/rstone/git/vll/tmp/usr/bin/cc
I think that this (in Makefile.incl1) might be the culprit?
# dtrace tools are required for older bootstrap env and cross-build
.if ${MK_CDDL} != no \
((${BOOTSTRAPPING} 800038 \
!(${BOOTSTRAPPING} = 700112 ${BOOTSTRAPPING} 79)) \
|| (${MACHINE} != ${TARGET} || ${MACHINE_ARCH} != ${TARGET_ARCH}))
_dtrace_tools= cddl/usr.bin/sgsmsg cddl/lib/libctf lib/libelf \
lib/libdwarf cddl/usr.bin/ctfconvert cddl/usr.bin/ctfmerge
.endif
___
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: API explosion (Re: [RFC/RFT] calloutng)
[top posting for readability; in summary we were discussing the new callout API trying to avoid an explosion of methods and arguments while at the same time supporting the old API and the new one] (I am also Cc-ing phk as he might have better insight on the topic). I think the patch you propose is a step in the right direction, but i still remain concerned by having to pass two bintimes (by reference, but they should really go by value) and one 'ticks' value to all these functions. I am also dubious that we need a full 128 bits to specify the 'precision': there would be absolutely no loss of functionality if we decided to specify the precision in powers of 2, so a precision 'k' (signed) means 2^k seconds. This way 8 bits are enough to represent any precision we want. The key difference between 'ticks' and bintimes (and the main difficulty in the conversion) is that ticks are relative and bintimes are interpreted as absolute. This could be easily solved by using a flag to specify if the 'bt' argument is absolute or relative, and passing the argument by value. So now the flags could contain C_DIRECT_EXEC, C_BT_IS_RELATIVE, the precision, and another 64 or 128 bit field contains the bintime. How does this look ? cheers luigi On 18.12.2012 20:03, Alexander Motin wrote: On 18.12.2012 19:36, Luigi Rizzo wrote: On Mon, Dec 17, 2012 at 11:03:53PM +0200, Alexander Motin wrote: I would instead do the following: I also don't very like the wide API and want to hear fresh ideas, but approaches to time measurement there are too different to do what you are proposing. Main problem is that while ticks value is relative, bintime is absolute. It is not easy to make conversion between them fast and precise. I've managed to do it, but the only function that does it now is _callout_reset_on(). All other functions are just passing values down. I am not sure I want to duplicate that code in each place, though doing it at least for for callout may be a good idea. I am afraid the above is not convincing. Most/all of the APIs i mentioned still have the conversion from ticks to bintime, and the code in your patch is just building multiple parallel paths (one for each of the three versions of the same function) to some final piece of code where the conversion takes place. The problem is that all of this goes through a set of obfuscating macros and the end result is horrible. To be clear, i believe the work you have been doing on cleaning up callout is great, i am just saying that this is the time to look at the code from a few steps away and clean up all those design decisions that perhaps were made in a haste to make things work. I will give you another example to show how convoluted is the code now: cv_timedwait() and cv_timedwait_sig() now have three versions each (plain, bt, flags). These six are remapped through macros to two functions, _cv_timedwait() and _cv_timedwait_sig(), with a possible bug (cv_timedwait_bt() maps to _cv_timedwait_sig() ) These two _cv_timedwait*() take both ticks and bintimes, and contain this sequence: +if (bt == NULL) +sleepq_set_timeout_flags(cvp, timo, flags); +else +sleepq_set_timeout_bt(cvp, bt, precision); Guess what, both sleepq_* are macros that remap to the same _sleepq_set_timeout(...) . So the above if (bt == NULL) is useless. But then if you dig into _sleepq_set_timeout() you'll see +if (bt == NULL) +callout_reset_flags_on(td-td_slpcallout, timo, +sleepq_timeout, td, PCPU_GET(cpuid), flags | C_DIRECT_EXEC); +else +callout_reset_bt_on(td-td_slpcallout, bt, precision, +sleepq_timeout, td, PCPU_GET(cpuid), flags | C_DIRECT_EXEC); and again both callout_reset*() are again remapped through macros to _callout_reset_on(), so another useless if (bt == NULL) And in the end you have the conversion from ticks to bintime. So basically the code path for cv_timedwait() has those two useless switches and one useless extra argument, and the conversion from ticks to bintime is down deep down in _callout_reset_on() where it can only be resolved at runtime, whereas by doing the conversion at the beginning the decision could have been made at compile time. So I believe my proposal would give large simplifications in the code and lead to a much cleaner implementation of what you have designed: 1. acknowledge the fact that the only representation of time that callouts use internally is a bintime+precision, define one single function (instead of two or three or six) that implements the blessed API, and implement the others with macros or inline functions doing the appropriate conversions; 2. specifically, the *_flags() variant has no reason to exist. It can be implemented through the *_bt() variant, and being a new function the only places where you introduce it require manual modifications so you can
Re: API explosion (Re: [RFC/RFT] calloutng)
On Tue, 2012-12-18 at 23:58 +0100, Luigi Rizzo wrote: [top posting for readability; in summary we were discussing the new callout API trying to avoid an explosion of methods and arguments while at the same time supporting the old API and the new one] (I am also Cc-ing phk as he might have better insight on the topic). I think the patch you propose is a step in the right direction, but i still remain concerned by having to pass two bintimes (by reference, but they should really go by value) and one 'ticks' value to all these functions. I am also dubious that we need a full 128 bits to specify the 'precision': there would be absolutely no loss of functionality if we decided to specify the precision in powers of 2, so a precision 'k' (signed) means 2^k seconds. This way 8 bits are enough to represent any precision we want. The key difference between 'ticks' and bintimes (and the main difficulty in the conversion) is that ticks are relative and bintimes are interpreted as absolute. This could be easily solved by using a flag to specify if the 'bt' argument is absolute or relative, and passing the argument by value. So now the flags could contain C_DIRECT_EXEC, C_BT_IS_RELATIVE, the precision, and another 64 or 128 bit field contains the bintime. How does this look ? cheers luigi I tend to agree that the bintime should be passed by value instead of reference. That would allow an inline tickstobintime() that converts relative ticks to an absolute bintime returned by value and passed right along in one tidy line/clump of code without any temporary variables cluttering things up. While the 1980s C programmer in me still wants to avoid returning complex objects by value, the reality is that modern compilers tend to generate really nice code for such constructs, usually without any copying of the return value at all. I'm not so sure about the 2^k precision. You speak of seconds, but I would be worrying about sub-second precision in my work. It would typical to want a 500uS timeout but be willing to late by up to 250uS if that helped scheduling and performance. Also, my idea of precision would virtually always be I'm willing to be late by this much, but never early by any amount. To reinforce the point of that last paragraph... the way I'm looking at these changes has nothing to do with power saving (I've never owned a battery-operated computer, probably never will) and everything to do with performance and being able to sleep accurately for less than a tick. -- Ian On 18.12.2012 20:03, Alexander Motin wrote: On 18.12.2012 19:36, Luigi Rizzo wrote: On Mon, Dec 17, 2012 at 11:03:53PM +0200, Alexander Motin wrote: I would instead do the following: I also don't very like the wide API and want to hear fresh ideas, but approaches to time measurement there are too different to do what you are proposing. Main problem is that while ticks value is relative, bintime is absolute. It is not easy to make conversion between them fast and precise. I've managed to do it, but the only function that does it now is _callout_reset_on(). All other functions are just passing values down. I am not sure I want to duplicate that code in each place, though doing it at least for for callout may be a good idea. I am afraid the above is not convincing. Most/all of the APIs i mentioned still have the conversion from ticks to bintime, and the code in your patch is just building multiple parallel paths (one for each of the three versions of the same function) to some final piece of code where the conversion takes place. The problem is that all of this goes through a set of obfuscating macros and the end result is horrible. To be clear, i believe the work you have been doing on cleaning up callout is great, i am just saying that this is the time to look at the code from a few steps away and clean up all those design decisions that perhaps were made in a haste to make things work. I will give you another example to show how convoluted is the code now: cv_timedwait() and cv_timedwait_sig() now have three versions each (plain, bt, flags). These six are remapped through macros to two functions, _cv_timedwait() and _cv_timedwait_sig(), with a possible bug (cv_timedwait_bt() maps to _cv_timedwait_sig() ) These two _cv_timedwait*() take both ticks and bintimes, and contain this sequence: +if (bt == NULL) +sleepq_set_timeout_flags(cvp, timo, flags); +else +sleepq_set_timeout_bt(cvp, bt, precision); Guess what, both sleepq_* are macros that remap to the same _sleepq_set_timeout(...) . So the above if (bt == NULL) is useless. But then if you dig into _sleepq_set_timeout() you'll see +if (bt == NULL) +callout_reset_flags_on(td-td_slpcallout, timo, +sleepq_timeout, td, PCPU_GET(cpuid), flags | C_DIRECT_EXEC); +else +
Re: API explosion (Re: [RFC/RFT] calloutng)
On Tue, Dec 18, 2012 at 04:27:45PM -0700, Ian Lepore wrote: On Tue, 2012-12-18 at 23:58 +0100, Luigi Rizzo wrote: [top posting for readability; in summary we were discussing the new callout API trying to avoid an explosion of methods and arguments while at the same time supporting the old API and the new one] (I am also Cc-ing phk as he might have better insight on the topic). I think the patch you propose is a step in the right direction, but i still remain concerned by having to pass two bintimes (by reference, but they should really go by value) and one 'ticks' value to all these functions. I am also dubious that we need a full 128 bits to specify the 'precision': there would be absolutely no loss of functionality if we decided to specify the precision in powers of 2, so a precision 'k' (signed) means 2^k seconds. This way 8 bits are enough to represent any precision we want. ... I'm not so sure about the 2^k precision. You speak of seconds, but I would be worrying about sub-second precision in my work. It would typical to want a 500uS timeout but be willing to late by up to 250uS if i said k is signed so negative values represent fractions of a second. 2^-128 is pretty short :) cheers luigi ___ 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: API explosion (Re: [RFC/RFT] calloutng)
On Wed, 2012-12-19 at 00:29 +0100, Luigi Rizzo wrote: On Tue, Dec 18, 2012 at 04:27:45PM -0700, Ian Lepore wrote: On Tue, 2012-12-18 at 23:58 +0100, Luigi Rizzo wrote: [top posting for readability; in summary we were discussing the new callout API trying to avoid an explosion of methods and arguments while at the same time supporting the old API and the new one] (I am also Cc-ing phk as he might have better insight on the topic). I think the patch you propose is a step in the right direction, but i still remain concerned by having to pass two bintimes (by reference, but they should really go by value) and one 'ticks' value to all these functions. I am also dubious that we need a full 128 bits to specify the 'precision': there would be absolutely no loss of functionality if we decided to specify the precision in powers of 2, so a precision 'k' (signed) means 2^k seconds. This way 8 bits are enough to represent any precision we want. ... I'm not so sure about the 2^k precision. You speak of seconds, but I would be worrying about sub-second precision in my work. It would typical to want a 500uS timeout but be willing to late by up to 250uS if i said k is signed so negative values represent fractions of a second. 2^-128 is pretty short :) cheers luigi Ahh, I missed that. Good enough then! Hmmm, if that ideas survives further review, then could precision be encoded in 8 bits of the flags, eliminating another parm? -- Ian ___ 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: API explosion (Re: [RFC/RFT] calloutng)
On Tue, Dec 18, 2012 at 04:37:10PM -0700, Ian Lepore wrote: On Wed, 2012-12-19 at 00:29 +0100, Luigi Rizzo wrote: On Tue, Dec 18, 2012 at 04:27:45PM -0700, Ian Lepore wrote: On Tue, 2012-12-18 at 23:58 +0100, Luigi Rizzo wrote: [top posting for readability; in summary we were discussing the new callout API trying to avoid an explosion of methods and arguments while at the same time supporting the old API and the new one] (I am also Cc-ing phk as he might have better insight on the topic). I think the patch you propose is a step in the right direction, but i still remain concerned by having to pass two bintimes (by reference, but they should really go by value) and one 'ticks' value to all these functions. I am also dubious that we need a full 128 bits to specify the 'precision': there would be absolutely no loss of functionality if we decided to specify the precision in powers of 2, so a precision 'k' (signed) means 2^k seconds. This way 8 bits are enough to represent any precision we want. ... I'm not so sure about the 2^k precision. You speak of seconds, but I would be worrying about sub-second precision in my work. It would typical to want a 500uS timeout but be willing to late by up to 250uS if i said k is signed so negative values represent fractions of a second. 2^-128 is pretty short :) cheers luigi Ahh, I missed that. Good enough then! Hmmm, if that ideas survives further review, then could precision be encoded in 8 bits of the flags, eliminating another parm? that was also what i wrote later in the message :) now we should figure out some use for the remaining 22 bits of the flags cheers luigi ___ 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: Failed to initialize dwarf?
On 12/18/12 07:15, Dimitry Andric wrote: On 2012-12-18 12:30, George Mitchell wrote: I checked out head Sunday and now my attempt at building a kernel says: ERROR: ctfconvert: failed to initialize DWARF: Unimplemented code at [dwarf_init_attr(400)] on every module it compiles (though it seems happy enough to keep compiling). Should I just ignore this?-- George Mitchell This problem was fixed in libdwarf in r239872; did you run make buildworld before make buildkernel? Yes. svnversion . says I have 244356. I'll try again. -- George ___ 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: ipv6_addrs_IF aliases in rc.conf(5)
On Fri, Dec 7, 2012 at 12:42 PM, Kimmo Paasiala kpaas...@gmail.com wrote: Hello, I wrote a small patch for /etc/network.subr to add support for ipv6_addrs_IF aliases in rc.conf(5) to match the already existing ipv4_addrs_IF aliases for ipv4 addresses. With this patch the ipv6 aliases can be written like: ipv6_addrs_re0=2001:db8::::1/64 2001:db8::::2/64 Only this syntax is supported, it's not possible to use the prefixlen nn syntax in the list. The patch is against a recent 9-STABLE, last changed rev of network.subr on my SVN checkout is r242187. I don't have a CURRENT system to test if it applies to CURRENT as well. The patch can be found attached to a PR I sent: http://www.freebsd.org/cgi/query-pr.cgi?pr=174225 I wrote this patch inspired by a question on the FreeBSD forums: http://forums.freebsd.org/showthread.php?t=36136 Please test and report if it works for you :) Regards, Kimmo Paasiala Hello, Did anyone try my patch? I thought it would be nice to have the ipv6_addrs_IF syntax supported to complement the existing ipv4_addrs_IF alias syntax. -Kimmo ___ 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
