false alarm (Re: __builtin_memcpy() slower than memcpy/bcopy (and on linux it is the opposite) ?)
On Wed, Jan 23, 2013 at 05:32:38PM +0100, Luigi Rizzo wrote: > Probably our compiler folks have some ideas on this... > > When doing netmap i found that on FreeBSD memcpy/bcopy was expensive, > __builtin_memcpy() was even worse, and so i ended up writing > my custom routine, (called pkt_copy() in the program below). > This happens with gcc 4.2.1, clang, gcc 4.6.4 > > I was then surprised to notice that on a recent ubuntu using > gcc 4.6.2 (if that matters) the __builtin_memcpy beats other > methods by a large factor. so, it turns out that in my test program I had swapped the source and destination operands for __builtin_memcpy(), and this substantially changed the memory access pattern. With the correct operands, __builtin_memcpy == memcpy == bcopy on both FreeBSD and Linux. On FreeBSD pkt_copy is still faster than the other methods for small packets, whereas on Linux they are equivalent. If you are curious why swapping source and dst changed things so dramatically: the test was supposed to read from a large chunk of memory (over 1GB) to avoid always hitting L1 or L2. Swapping operands causes reads to hit always the same line, thus saving a lot of misses. The difference between the two machine then probably is due to how the cache is used on writes. sorry for the noise. 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: ACPI panic on unplugging the power cord.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2013-01-22 12:56:29 -0500, Pawel Jakub Dawidek wrote:
> I just upgraded to HEAD today and was wondering what will explode.
> Now I know.
>
> When I unplug power cord from my laptop, ACPI panics. Pictures
> here:
>
> http://people.freebsd.org/~pjd/misc/acpi_panic_0.jpg
> http://people.freebsd.org/~pjd/misc/acpi_panic_1.jpg
>
> Let me know if you need more info.
Can you please try the attached patch? It is also available from here:
http://people.freebsd.org/~jkim/utcache.diff
Please note the patch may or may not fix the problem but I think I
found an ancient bug. :-(
Thanks,
Jung-uk Kim
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (FreeBSD)
iQEcBAEBAgAGBQJRAIZhAAoJECXpabHZMqHOWl8H/3pUGshUkzCNbEOQHoZOYXMW
TtLaUqdV3/zYGEYDYl5Tbxv2JUz4tWDU5KlWhnZk+MjNnR1+g0fgzQu3mK056NU+
rpZucEnoaEeKriLpd+Hsw3Y28eXiY8/9T8/SnFMUW7AS6HZk8G7itdu9cx9A+IY6
A2tQBIpDXes4a5BLNZzyP/2dSMrcKVeS28+fZlxGdWWakFs5/FWYguK5kR2PIkCS
3yh8vEv7XH8WJz+sK/v/jcpcxt+heCG+j8XIwJieqk1CDXaCtH6g+4mlKQogsZY1
1YSYaGE+/szNvnR9UjW1+x/mhA5atFa9ysCq96zvVOs/Ih7X9Id4fZ6laetSDIs=
=rUXs
-END PGP SIGNATURE-
Index: sys/contrib/dev/acpica/components/utilities/utcache.c
===
--- sys/contrib/dev/acpica/components/utilities/utcache.c (revision 245848)
+++ sys/contrib/dev/acpica/components/utilities/utcache.c (working copy)
@@ -95,7 +95,6 @@ AcpiOsCreateCache (
/* Populate the cache object and return it */
ACPI_MEMSET (Cache, 0, sizeof (ACPI_MEMORY_LIST));
-Cache->LinkOffset = 8;
Cache->ListName = CacheName;
Cache->ObjectSize = ObjectSize;
Cache->MaxDepth = MaxDepth;
@@ -121,7 +120,7 @@ ACPI_STATUS
AcpiOsPurgeCache (
ACPI_MEMORY_LIST*Cache)
{
-char*Next;
+void*Next;
ACPI_STATUS Status;
@@ -145,8 +144,7 @@ AcpiOsPurgeCache (
{
/* Delete and unlink one cached state object */
-Next = *(ACPI_CAST_INDIRECT_PTR (char,
-&(((char *) Cache->ListHead)[Cache->LinkOffset])));
+Next = ((ACPI_OBJECT_COMMON *) Cache->ListHead)->NextObject;
ACPI_FREE (Cache->ListHead);
Cache->ListHead = Next;
@@ -251,8 +249,7 @@ AcpiOsReleaseObject (
/* Put the object at the head of the cache list */
-* (ACPI_CAST_INDIRECT_PTR (char,
-&(((char *) Object)[Cache->LinkOffset]))) = Cache->ListHead;
+((ACPI_OBJECT_COMMON *) Object)->NextObject = Cache->ListHead;
Cache->ListHead = Object;
Cache->CurrentDepth++;
@@ -307,8 +304,7 @@ AcpiOsAcquireObject (
/* There is an object available, use it */
Object = Cache->ListHead;
-Cache->ListHead = *(ACPI_CAST_INDIRECT_PTR (char,
-&(((char *) Object)[Cache->LinkOffset])));
+Cache->ListHead = ((ACPI_OBJECT_COMMON *) Object)->NextObject;
Cache->CurrentDepth--;
Index: sys/contrib/dev/acpica/include/actypes.h
===
--- sys/contrib/dev/acpica/include/actypes.h (revision 245848)
+++ sys/contrib/dev/acpica/include/actypes.h (working copy)
@@ -1226,7 +1226,6 @@ typedef struct acpi_memory_list
UINT16 ObjectSize;
UINT16 MaxDepth;
UINT16 CurrentDepth;
-UINT16 LinkOffset;
#ifdef ACPI_DBG_TRACK_ALLOCATIONS
___
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"
/usr/bin/ld: final link failed: Bad value
FreeBSD FBSD10 10.0-CURRENT FreeBSD 10.0-CURRENT #30 r245800: Tue Jan 22 13:00:27 EST 2013 root@FBSD10:/usr/obj/usr/src/sys/MYKERNEL amd64 Could someone please comment on this. I am trying to build and install FireFox Nightly. This is not the Firefox version in the ports tree, it is from here: https://trillian.chruetertee.ch/svn/freebsd-gecko/trunk/www/firefox-nightly/ I did an svn co to /usr/ports/www/FF_nightly and use this command to build and install: make update && make makesum && time make all deinstall install clean Here is the error: c++ -o nsRDFResource.o -c -I../../dist/stl_wrappers -I../../dist/system_wrappers -include ../../../config/gcc_hidden.h -DMOZ_JSDEBUGGER -DMOZ_PREF_EXTENSIONS -DMOZ_AUTH_EXTENSION -DMOZ_PERMISSIONS -DMOZ_UNIVERSALCHARDET -DMOZ_FILEVIEW -DICON_DECODER -DMOZ_SPELLCHECK -DMOZ_ZIPWRITER -DIMPL_XREAPI -DMOZ_GLUE_IN_PROGRAM -DMOZILLA_INTERNAL_API -DNO_NSPR_10_SUPPORT -D_IMPL_NS_COM -D_IMPL_NS_STRINGAPI -DEXPORT_XPT_API -DEXPORT_XPTC_API -D_IMPL_NS_GFX -D_IMPL_NS_WIDGET -I../../../intl/unicharutil/util -I../../../intl/unicharutil/src -I../../../config -I../../../widget/windows -I../../../toolkit/library -I. -I../../dist/include -I/usr/local/include/nspr -I/usr/ports/www/FF_nightly/work/mozilla-central-70baa7e07838/obj-x86_64-portbld-freebsd10.0/dist/include/nss -I/usr/local/include -I/usr/local/include-fPIC -Qunused-arguments -isystem/usr/local/include -I/usr/local/include -Qunused-arguments -Wall -Wpointer-arith -Woverloaded-virtual -Werror=return-type -Wtype-limits -Wempty-body -Wno-invalid-offsetof -Wno-c++0x-extensions -Wno-extended-offsetof -Wno-unknown-warning-option -Wno-return-type-c-linkage -Wno-mismatched-tags -O2 -pipe -fno-strict-aliasing -fno-exceptions -fno-strict-aliasing -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -std=gnu++0x -pipe -DNDEBUG -DTRIMMED -O2 -fomit-frame-pointer -Qunused-arguments -isystem/usr/local/include -I/usr/local/include -DMOZILLA_CLIENT -include ../../mozilla-config.h -MD -MF .deps/nsRDFResource.o.pp /usr/ports/www/FF_nightly/work/mozilla-central-70baa7e07838/obj-x86_64-portbld-freebsd10.0/toolkit/library/nsRDFResource.cpp rm -f libxul.so /usr/ports/www/FF_nightly/work/mozilla-central-70baa7e07838/obj-x86_64-portbld-freebsd10.0/_virtualenv/bin/python ../../../config/expandlibs_exec.py --depend .deps/libxul.so.pp --target libxul.so --uselist -- c++ -Qunused-arguments -isystem/usr/local/include -I/usr/local/include -Qunused-arguments -Wall -Wpointer-arith -Woverloaded-virtual -Werror=return-type -Wtype-limits -Wempty-body -Wno-invalid-offsetof -Wno-c++0x-extensions -Wno-extended-offsetof -Wno-unknown-warning-option -Wno-return-type-c-linkage -Wno-mismatched-tags -O2 -pipe -fno-strict-aliasing -fno-exceptions -fno-strict-aliasing -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -std=gnu++0x -pipe -DNDEBUG -DTRIMMED -O2 -fomit-frame-pointer -fPIC -shared -Wl,-z,defs -Wl,-h,libxul.so -o libxul.so nsStaticXULComponents.o nsUnicharUtils.o nsBidiUtils.o nsSpecialCasingData.o nsUnicodeProperties.o nsRDFResource.o-pthread -L/usr/local/lib -Wl,-z,origin -Wl,-rpath,\$ORIGIN -Wl,-z,noexecstack -Wl,-rpath-link,/usr/ports/www/FF_nightly/work/mozilla-central-70baa7e07838/obj-x86_64-portbld-freebsd10.0/dist/bin -Wl,-rpath-link,/usr/local/lib ../../toolkit/components/osfile/libosfile_s.a ../../toolkit/xre/libxulapp_s.a ../../staticlib/components/libnecko.a ../../staticlib/components/libuconv.a ../../staticlib/components/libi18n.a ../../staticlib/components/libchardet.a ../../staticlib/components/libjar50.a ../../staticlib/components/libstartupcache.a ../../staticlib/components/libpref.a ../../staticlib/components/libhtmlpars.a ../../staticlib/components/libidentity.a ../../staticlib/components/libimglib2.a ../../staticlib/components/libmediasniffer.a ../../staticlib/components/libgkgfx.a ../../staticlib/components/libgklayout.a ../../staticlib/components/libdocshell.a ../../staticlib/components/libembedcomponents.a ../../staticlib/components/libwebbrwsr.a ../../staticlib/components/libnsappshell.a ../../staticlib/components/libtxmgr.a ../../staticlib/components/libcommandlines.a ../../staticlib/components/libtoolkitcomps.a ../../staticlib/components/libpipboot.a ../../staticlib/components/libpipnss.a ../../staticlib/components/libappcomps.a ../../staticlib/components/libjsreflect.a ../../staticlib/components/libcomposer.a ../../staticlib/components/libtelemetry.a ../../staticlib/components/libjsinspector.a ../../staticlib/components/libjsdebugger.a ../../staticlib/components/libstoragecomps.a ../../staticlib/components/librdf.a ../../staticlib/components/libwindowds.a ../../staticlib/components/libjsctypes.a ../../staticlib/components/libjsperf.a ../../staticlib/components/libgkplugin.a ../../staticlib/components/libunixproxy.a ../../staticlib/components/libjsd.a ../../staticlib/components/libautoconfig.a ../../st
Re: __builtin_memcpy() slower than memcpy/bcopy (and on linux it is the opposite) ?
On Wed, Jan 23, 2013 at 11:29 AM, Artem Belevich wrote: > On Wed, Jan 23, 2013 at 8:32 AM, Luigi Rizzo wrote: > > Probably our compiler folks have some ideas on this... > > > > When doing netmap i found that on FreeBSD memcpy/bcopy was expensive, > > __builtin_memcpy() was even worse, and so i ended up writing > > my custom routine, (called pkt_copy() in the program below). > > This happens with gcc 4.2.1, clang, gcc 4.6.4 > > The program does not seem to have pkt_copy. It does have fast_bcopy. > Is that the one you meant by pkt_copy? > > sorry for the confusion, i did some last-minute name changes. pkt_copy() is the name of the C function, ./testloop -m fastcopy is the name you need to use to run pkt_copy() 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: __builtin_memcpy() slower than memcpy/bcopy (and on linux it is the opposite) ?
On Wed, Jan 23, 2013 at 11:26 AM, Dimitry Andric wrote: > Which compilation flags did you use to test this? When I compiled your > testcase program with clang 3.2, gcc 4.2 and gcc 4.7 at -O2, with all > other settings at their defaults, all three compilers just called libc's > memcpy() for the __builtin_memcpy tests. > just -O2 -Wall -Werror, no special -m* or -f* 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: panic after r244584
On Jan 23, 2013, at 1:39 PM, Alexander Motin wrote: > On 23.01.2013 21:51, Jaakko Heinonen wrote: >> On 2013-01-23, Vitalij Satanivskij wrote: >>> VS> Jaakko Heinonen wrote: >>> VS> JH> > I see two possible solutions for the problem. >>> VS> JH> > >>> VS> JH> > 1) Replace non-printable, space and '/' characters for example >>> with '_'. >>> VS> JH> >'/' should be replaced anyway. >>> VS> JH> > >>> VS> JH> > 2) Apply the patches in >>> VS> JH> > >>> http://lists.freebsd.org/pipermail/svn-src-all/2013-January/063661.html >>> VS> JH> >to allow spaces again. I haven't committed the patches because >>> I >>> VS> JH> >think that there isn't full consensus that it's right thing to >>> do and >>> VS> JH> >also I personally prefer not to have spaces in device names. >>> VS> JH> >>> VS> JH> Here's a patch to implement 1: >>> VS> JH> >>> VS> JH> http://people.freebsd.org/~jh/patches/scsi_enc_ses-si_name.diff >>> VS> >>> VS> Ok that patch work's too. >>> >>> Is there any chance, that one of this patches will be merged to head? >> >> Yes. >> >> Alexander and Justin: what do you think about this patch? >> >> http://people.freebsd.org/~jh/patches/scsi_enc_ses-si_name.diff > > It is fine for me, or at least better then panic. But that is Justin's > code, so he should know better. It's fine. -- Justin ___ 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: panic after r244584
On 23.01.2013 21:51, Jaakko Heinonen wrote: > On 2013-01-23, Vitalij Satanivskij wrote: >> VS> Jaakko Heinonen wrote: >> VS> JH> > I see two possible solutions for the problem. >> VS> JH> > >> VS> JH> > 1) Replace non-printable, space and '/' characters for example >> with '_'. >> VS> JH> >'/' should be replaced anyway. >> VS> JH> > >> VS> JH> > 2) Apply the patches in >> VS> JH> > >> http://lists.freebsd.org/pipermail/svn-src-all/2013-January/063661.html >> VS> JH> >to allow spaces again. I haven't committed the patches because I >> VS> JH> >think that there isn't full consensus that it's right thing to >> do and >> VS> JH> >also I personally prefer not to have spaces in device names. >> VS> JH> >> VS> JH> Here's a patch to implement 1: >> VS> JH> >> VS> JH> http://people.freebsd.org/~jh/patches/scsi_enc_ses-si_name.diff >> VS> >> VS> Ok that patch work's too. >> >> Is there any chance, that one of this patches will be merged to head? > > Yes. > > Alexander and Justin: what do you think about this patch? > > http://people.freebsd.org/~jh/patches/scsi_enc_ses-si_name.diff It is fine for me, or at least better then panic. But that is Justin's code, so he should know better. -- 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: Adding more tools to be used by operator group members
On Tue, Jan 22, 2013 at 10:38 AM, Adrian Chadd wrote: > Ah, the historical difference between shutdown -r and reboot > > > adrian > > On 22 January 2013 09:59, Gleb Smirnoff wrote: >> On Tue, Jan 22, 2013 at 02:03:12PM +0100, Olivier Cochard-Labb? wrote: >> O> There are only 2 useable tools by "operator" group members: >> O> shutdown (and its child: poweroff, halt, etc?) and mksnap_ffs. >> O> >> O> On my HAL-less laptop, I've put my user in the operator group that let >> O> me reboot/power-off it with shutdown. >> O> But I would to be able to suspend-resume it too (with zzz). >> O> >> O> Here is what I've did: >> O> for f in "/usr/sbin/acpiconf /usr/sbin/apm"; do >> O> chown :operator $f >> O> chmod 4550 $f >> O> done >> O> >> O> What about configuring this permission by default on FreeBSD ? >> O> And why /sbin/reboot isn't useable by operator too ? >> O> Are there somes security issue ? >> >> +1 here. I was always annoyed and surprised by this fact. >> >> -- >> Totus tuus, Glebius. While reboot is dangerous and should really only be used in single user mode or an emergency, I don't understood why operator was not allowed to do it. for those who assume that "reboot" is short for "shutdown -r now", it is not. Reboot does not bother shutting down stuff in rc.d while shutdown does. This can result in shutdown not working, but reboot can leave things like database files in bad shape. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic after r244584
On 2013-01-23, Vitalij Satanivskij wrote: > VS> Jaakko Heinonen wrote: > VS> JH> > I see two possible solutions for the problem. > VS> JH> > > VS> JH> > 1) Replace non-printable, space and '/' characters for example with > '_'. > VS> JH> >'/' should be replaced anyway. > VS> JH> > > VS> JH> > 2) Apply the patches in > VS> JH> > > http://lists.freebsd.org/pipermail/svn-src-all/2013-January/063661.html > VS> JH> >to allow spaces again. I haven't committed the patches because I > VS> JH> >think that there isn't full consensus that it's right thing to > do and > VS> JH> >also I personally prefer not to have spaces in device names. > VS> JH> > VS> JH> Here's a patch to implement 1: > VS> JH> > VS> JH> http://people.freebsd.org/~jh/patches/scsi_enc_ses-si_name.diff > VS> > VS> Ok that patch work's too. > > Is there any chance, that one of this patches will be merged to head? Yes. Alexander and Justin: what do you think about this patch? http://people.freebsd.org/~jh/patches/scsi_enc_ses-si_name.diff -- Jaakko ___ 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: __builtin_memcpy() slower than memcpy/bcopy (and on linux it is the opposite) ?
On Wed, Jan 23, 2013 at 8:32 AM, Luigi Rizzo wrote: > Probably our compiler folks have some ideas on this... > > When doing netmap i found that on FreeBSD memcpy/bcopy was expensive, > __builtin_memcpy() was even worse, and so i ended up writing > my custom routine, (called pkt_copy() in the program below). > This happens with gcc 4.2.1, clang, gcc 4.6.4 The program does not seem to have pkt_copy. It does have fast_bcopy. Is that the one you meant by pkt_copy? --Artem ___ 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: __builtin_memcpy() slower than memcpy/bcopy (and on linux it is the opposite) ?
On 2013-01-23 17:32, Luigi Rizzo wrote: Probably our compiler folks have some ideas on this... When doing netmap i found that on FreeBSD memcpy/bcopy was expensive, __builtin_memcpy() was even worse, Which compilation flags did you use to test this? When I compiled your testcase program with clang 3.2, gcc 4.2 and gcc 4.7 at -O2, with all other settings at their defaults, all three compilers just called libc's memcpy() for the __builtin_memcpy tests. For example, with gcc 4.7, the loop in test_builtin_memcpy becomes: .L116: movq%rbx, %rax addq$1, %rbx andl$262143, %eax movq%rax, %rdx salq$12, %rax salq$8, %rdx leaqhuge(%rdx,%rax), %rsi movq%r12, %rdx callmemcpy movq24(%rbp), %rax movq0(%rbp), %rdi addq$1, %rax cmpq%rbx, 4096(%rdi) movq%rax, 24(%rbp) jg .L116 The other routines are emitted as similar code. For test_bcopy() the loop becomes: .L123: movq%rbx, %rax addq$1, %rbx andl$262143, %eax movq%rax, %rdx salq$12, %rax salq$8, %rdx leaqhuge(%rdx,%rax), %rsi movq%r12, %rdx callbcopy movq24(%rbp), %rax movq0(%rbp), %rdi addq$1, %rax cmpq%rbx, 4096(%rdi) movq%rax, 24(%rbp) jg .L123 and similarly, for test_memcpy() it becomes: .L109: movq%rbx, %rax addq$1, %rbx andl$262143, %eax movq%rax, %rdx salq$12, %rax salq$8, %rdx leaqhuge(%rdx,%rax), %rdi movq%r12, %rdx callmemcpy movq24(%rbp), %rax movq0(%rbp), %rsi addq$1, %rax cmpq%rbx, 4096(%rsi) movq%rax, 24(%rbp) jg .L109 In our libc, bcopy and memcpy are implemented from the same source file, which just the arguments swapped around. So I fail to see what could cause the performance difference between __builtin_memcpy, memcpy and bcopy you are seeing. Also, on amd64, this is implemented in lib/libc/amd64/string/bcopy.S, so the compiler does not have any influence on its performance. Note the routine uses "rep movsq" as its main loop, which is apparently not the best way on modern CPUs. Maybe you have found another instance where hand-rolled assembly is slower than compiler-optimized code... :-) With gcc 4.7, your fast_bcopy() gets inlined to this: .L131: movq(%rax), %rdx subl$64, %ecx movq%rdx, (%rsi) movq8(%rax), %rdx movq%rdx, 8(%rsi) movq16(%rax), %rdx movq%rdx, 16(%rsi) movq24(%rax), %rdx movq%rdx, 24(%rsi) movq32(%rax), %rdx movq%rdx, 32(%rsi) movq40(%rax), %rdx movq%rdx, 40(%rsi) movq48(%rax), %r9 movq%r9, 48(%rsi) movq56(%rax), %r9 addq$64, %rax movq%r9, 56(%rsi) addq$64, %rsi testl %ecx, %ecx jg .L131 while clang 3.2 produces: .LBB14_5: movq(%rdi), %rcx movq%rcx, (%rsi) movq8(%rdi), %rcx movq%rcx, 8(%rsi) movq16(%rdi), %rcx movq%rcx, 16(%rsi) addl$-64, %eax movq24(%rdi), %rcx movq%rcx, 24(%rsi) testl %eax, %eax movq32(%rdi), %rcx movq%rcx, 32(%rsi) movq40(%rdi), %rcx movq%rcx, 40(%rsi) movq48(%rdi), %rcx movq%rcx, 48(%rsi) movq56(%rdi), %rcx leaq64(%rdi), %rdi movq%rcx, 56(%rsi) leaq64(%rsi), %rsi jg .LBB14_5 Both are most likely faster than the "rep movsq" logic in bcopy.S. and so i ended up writing my custom routine, (called pkt_copy() in the program below). This happens with gcc 4.2.1, clang, gcc 4.6.4 I was then surprised to notice that on a recent ubuntu using gcc 4.6.2 (if that matters) the __builtin_memcpy beats other methods by a large factor. On Ubuntu, I see the same thing as on FreeBSD; __builtin_memcpy just calls the regular memcpy. However, eglibc's memcpy looks to be more highly optimized; there are several CPU-specific implementations, for example for i386 and amd64 arches: sysdeps/i386/i586/memcpy_chk.S sysdeps/i386/i586/memcpy.S sysdeps/i386/i686/memcpy_chk.S sysdeps/i386/i686/memcpy.S sysdeps/i386/i686/multiarch/memcpy_chk.S sysdeps/i386/i686/multiarch/memcpy.S sysdeps/i386/i686/multiarch/memcpy-ssse3-rep.S sysdeps/i386/i686/multiarch/memcpy-ssse3.S sysdeps/x86_64/memcpy_chk.S sysdeps/x86_64/memcpy.S sysdeps/x86_64/multiarch/memcpy_chk.S sysdeps/x86_64/multiarch/memcpy.S sysdeps/x86_64/multiarch/memcpy-ssse3-back.S sysdeps/x86_64/multiarch/memcpy-ssse3.S Most likely, your test prog
Re: Compilation error (pkgng)
On Jan 23, 2013, at 12:14 AM, Alie Tan wrote:
> Seems this check-in causing compilation error:
>
> http://freshbsd.org/commit/freebsd/r245828
>
> -nonliteral -c /usr/src/usr.sbin/pkg_install/lib/pkgng.c -o pkgng.o
> /usr/src/usr.sbin/pkg_install/lib/pkgng.c:53:45: error: expected ')'
>rc = snprintf(pkgngpath, sizeof(pkgngpath) "%s/local.sqlite",
> pkgngdir);
> ^
> /usr/src/usr.sbin/pkg_install/lib/pkgng.c:53:15: note: to match this '('
>rc = snprintf(pkgngpath, sizeof(pkgngpath) "%s/local.sqlite",
> pkgngdir);
> ^
> /usr/src/usr.sbin/pkg_install/lib/pkgng.c:54:9: warning: comparison of
> integers of different signs: 'int' and 'unsigned int' [-Wsign-compare]
>if (rc >= sizeof(pkgngpath)) {
>~~ ^ ~
> 1 warning and 1 error generated.
Fixed by r245837.
Thanks,
Jason
___
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"
__builtin_memcpy() slower than memcpy/bcopy (and on linux it is the opposite) ?
Probably our compiler folks have some ideas on this...
When doing netmap i found that on FreeBSD memcpy/bcopy was expensive,
__builtin_memcpy() was even worse, and so i ended up writing
my custom routine, (called pkt_copy() in the program below).
This happens with gcc 4.2.1, clang, gcc 4.6.4
I was then surprised to notice that on a recent ubuntu using
gcc 4.6.2 (if that matters) the __builtin_memcpy beats other
methods by a large factor.
Here are the number in millions of calls per second. Is the test
program flawed, or the compiler is built with different options ?
Unfortunately i have no chance to run the two versions of the code
on the same machine, but the hardware should be relatively similar
(i7-2600 i@ 3.4 GHz on one, Xeon E5-1650 @ 3.2 GHz on the other)
BSD / Linux
block size (bytes) 31 32 64 2048
__builtin_memcpy10 / 15013 / 15813 / 1525.1 /
23.2
memcpy 23 / 64 47 / 64 45 / 64 5.4 /
3.8
bcopy 24 / 64 47 / 64 45 / 63 5.4 /
3.8
pkt_copy65 / 63 65 / 63 64 / 63 5.5 /
3.7
cheers
luigi
/*
* Copyright (C) 2012 Luigi Rizzo. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
*documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*/
/*
* $Id: testlock.c 12015 2013-01-23 15:51:17Z luigi $
*
* Test program to study various ops and concurrency issues.
* Create multiple threads, possibly bind to cpus, and run a workload.
*
* cc -O2 -Werror -Wall testlock.c -o testlock -lpthread
* you might need -lrt
*/
#include
#include
#include /* pthread_* */
#if defined(__APPLE__)
#include
#define atomic_add_int(p, n) OSAtomicAdd32(n, (int *)p)
#define atomic_cmpset_32(p, o, n) OSAtomicCompareAndSwap32(o, n, (int *)p)
#elif defined(linux)
int atomic_cmpset_32(volatile uint32_t *p, uint32_t old, uint32_t new)
{
int ret = *p == old;
*p = new;
return ret;
}
#if defined(HAVE_GCC_ATOMICS)
int atomic_add_int(volatile int *p, int v)
{
return __sync_fetch_and_add(p, v);
}
#else
inline
uint32_t atomic_add_int(uint32_t *p, int v)
{
__asm __volatile (
" lock xaddl %0, %1 ;"
: "+r" (v), /* 0 (result) */
"=m" (*p) /* 1 */
: "m" (*p));/* 2 */
return (v);
}
#endif
#else /* FreeBSD */
#include
#include
#include /* pthread w/ affinity */
#if __FreeBSD_version > 50
#include /* cpu_set */
#if __FreeBSD_version > 80
#define HAVE_AFFINITY
#endif
inline void prefetch (const void *x)
{
__asm volatile("prefetcht0 %0" :: "m" (*(const unsigned long *)x));
}
#else /* FreeBSD 4.x */
int atomic_cmpset_32(volatile uint32_t *p, uint32_t old, uint32_t new)
{
int ret = *p == old;
*p = new;
return ret;
}
#define PRIu64 "llu"
#endif /* FreeBSD 4.x */
#endif /* FreeBSD */
#include /* signal */
#include
#include
#include
#include/* PRI* macros */
#include /* strcmp */
#include /* open */
#include /* getopt */
#include /* sysctl */
#include/* timersub */
static inline int min(int a, int b) { return a < b ? a : b; }
#define ONE_MILLION 100
/* debug support */
#define ND(format, ...)
#define D(format, ...) \
fprintf(stderr, "%s [%d] " format "\n", \
__FUNCTION__, __LINE__, ##__VA_ARGS__)
int verbose = 0;
#if 1//def MY_RDTSC
/* Wrapper around `rdtsc' to take reliable timestamps flushing the pipeline */
#define my_rdtsc(t) \
Re: serial console not accepting input?
On 2013-01-23 16:43, Eggert, Lars wrote: I'm embarrassed to ask this newbie question, but I'm at my wit's end: I've configured a serial console according to the handbook. I see the boot messages and get the login prompt. But at no point during the boot process does the console seem to accept any input, incl. when at the boot prompt. The same serial setup works fine with other boxes. Any ideas? CTS/RTS hardware flow control, maybe? E.g. add ":hw" to the default settings in /etc/gettytab, or make a specific entry with an added ":hw" setting. If it is a physical serial console, you could also simply have a bad cable. Try swapping it with working system. :) ___ 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"
serial console not accepting input?
Hi, I'm embarrassed to ask this newbie question, but I'm at my wit's end: I've configured a serial console according to the handbook. I see the boot messages and get the login prompt. But at no point during the boot process does the console seem to accept any input, incl. when at the boot prompt. The same serial setup works fine with other boxes. Any ideas? Thanks, Lars ___ 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: ZFS + usb in trouble?
On Wed, Jan 23, 2013 at 09:11:23PM +0900, Alexander Nedotsukov wrote: > And now both are failing, although zfs in a different way. Yes, but now we are sure this is not ZFS issue. Sequential read simply doesn't trigger the corruption, but ZFS access patterns do. The read errors you are seeing are due to GELI returning EIO on integrity verification error. > # zpool status > pool: testpool > state: ONLINE > status: One or more devices has experienced an unrecoverable error. An > attempt was made to correct the error. Applications are unaffected. > action: Determine if the device needs to be replaced, and clear the errors > using 'zpool clear' or replace the device with 'zpool replace'. >see: http://illumos.org/msg/ZFS-8000-9P > scan: scrub repaired 1M in 0h2m with 0 errors on Wed Jan 23 20:57:11 2013 > config: > > NAME STATE READ WRITE CKSUM > testpool ONLINE 0 0 0 > raidz1-0ONLINE 0 0 0 > da5.elid ONLINE 0 0 0 > da5.elie ONLINE 21 0 0 > da5.elif ONLINE 0 0 0 > > # dmesg | tail -20 > GEOM_ELI: da1.eli: Failed to authenticate 131072 bytes of data at offset > 1010827264. > ath0: bb hang detected (0x4), resetting > GEOM_ELI: Device da5.eli created. > GEOM_ELI: Encryption: AES-XTS 128 > GEOM_ELI: Integrity: HMAC/SHA1 > GEOM_ELI: Crypto: software > GEOM_ELI: da5.eli: Failed to authenticate 4096 bytes of data at offset 4096. > GEOM_ELI: da5.eli: Failed to authenticate 4096 bytes of data at offset 0. > GEOM_ELI: da5.eli: Failed to authenticate 5792 bytes of data at offset > 229288288. > GEOM_ELI: da5.eli: Failed to authenticate 65536 bytes of data at offset > 229429248. > GEOM_ELI: da5.eli: Failed to authenticate 131072 bytes of data at offset > 229298176. > GEOM_ELI: da5.eli: Failed to authenticate 26496 bytes of data at offset > 229494784. > GEOM_ELI: da5.eli: Failed to authenticate 12288 bytes of data at offset > 270299136. > GEOM_ELI: da5.eli: Failed to authenticate 65536 bytes of data at offset > 270319616. > GEOM_ELI: da5.eli: Failed to authenticate 5792 bytes of data at offset > 273095488. > GEOM_ELI: da5.eli: Failed to authenticate 56864 bytes of data at offset > 273105376. > GEOM_ELI: da5.eli: Failed to authenticate 2400 bytes of data at offset > 273326080. > GEOM_ELI: da5.eli: Failed to authenticate 65536 bytes of data at offset > 272560128. > GEOM_ELI: da5.eli: Failed to authenticate 131072 bytes of data at offset > 272429056. > GEOM_ELI: da5.eli: Failed to authenticate 32768 bytes of data at offset > 272396288. -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl pgpN4AvBRoAtD.pgp Description: PGP signature
Re: ZFS + usb in trouble?
On 23.01.2013, at 3:10, Pawel Jakub Dawidek wrote: > On Tue, Jan 22, 2013 at 11:47:29PM +0900, Alexander Nedotsukov wrote: >> Hi Pawel, >> >> Here what I did. >> >> # geli onetime -a hmac/sha1 -s 4096 /dev/da5 >> # dmesg | tail -15 >> wlan0: link state changed to UP >> ugen5.4: at usbus5 >> umass2: > 2.00/1.00, addr 4> on usbus5 >> umass2: SCSI over Bulk-Only; quirks = 0x0100 >> umass2:4:2:-1: Attached to scbus4 >> da5 at umass-sim2 bus 2 scbus4 target 0 lun 0 >> da5: Removable Direct Access SCSI-2 device >> da5: 40.000MB/s transfers >> da5: 983MB (2015231 512 byte sectors: 64H 32S/T 983C) >> GEOM_ELI: Device da5.eli created. >> GEOM_ELI: Encryption: AES-XTS 128 >> GEOM_ELI: Integrity: HMAC/SHA1 >> GEOM_ELI: Crypto: software >> GEOM_ELI: da5.eli: Failed to authenticate 4096 bytes of data at offset 4096. >> GEOM_ELI: da5.eli: Failed to authenticate 4096 bytes of data at offset 0. >> >> # dd if=/dev/random of=/dev/da5.eli bs=1m >> dd: /dev/da5.eli: short write on character device >> dd: /dev/da5.eli: end of device >> 875+0 records in >> 874+1 records out >> 917151744 bytes transferred in 1530.831674 secs (599120 bytes/sec) >> >> # dd if=/dev/da5.eli of=/dev/null bs=1m >> 874+1 records in >> 874+1 records out >> 917151744 bytes transferred in 178.874312 secs (5127353 bytes/sec) >> >> All clear. No new errors. >> >> Zpool created on the same usb stick is still failing with cksum errors. >> >> # usbconfig -d 5.4 add_quirk UQ_MSC_NO_SYNC_CACHE >> >> umass2: SCSI over Bulk-Only; quirks = 0x4000 >> >> Re-created zpool is still failing with cksum errors. Every new scrub run is >> triggering another "repairing". > > Interesting. Can you put ZFS on top of GELI with authentication after > filling da0.eli with random random and see if GELI will report > corruption when ZFS will or if only ZFS will report corruption? And now both are failing, although zfs in a different way. # zpool status pool: testpool state: ONLINE status: One or more devices has experienced an unrecoverable error. An attempt was made to correct the error. Applications are unaffected. action: Determine if the device needs to be replaced, and clear the errors using 'zpool clear' or replace the device with 'zpool replace'. see: http://illumos.org/msg/ZFS-8000-9P scan: scrub repaired 1M in 0h2m with 0 errors on Wed Jan 23 20:57:11 2013 config: NAME STATE READ WRITE CKSUM testpool ONLINE 0 0 0 raidz1-0ONLINE 0 0 0 da5.elid ONLINE 0 0 0 da5.elie ONLINE 21 0 0 da5.elif ONLINE 0 0 0 # dmesg | tail -20 GEOM_ELI: da1.eli: Failed to authenticate 131072 bytes of data at offset 1010827264. ath0: bb hang detected (0x4), resetting GEOM_ELI: Device da5.eli created. GEOM_ELI: Encryption: AES-XTS 128 GEOM_ELI: Integrity: HMAC/SHA1 GEOM_ELI: Crypto: software GEOM_ELI: da5.eli: Failed to authenticate 4096 bytes of data at offset 4096. GEOM_ELI: da5.eli: Failed to authenticate 4096 bytes of data at offset 0. GEOM_ELI: da5.eli: Failed to authenticate 5792 bytes of data at offset 229288288. GEOM_ELI: da5.eli: Failed to authenticate 65536 bytes of data at offset 229429248. GEOM_ELI: da5.eli: Failed to authenticate 131072 bytes of data at offset 229298176. GEOM_ELI: da5.eli: Failed to authenticate 26496 bytes of data at offset 229494784. GEOM_ELI: da5.eli: Failed to authenticate 12288 bytes of data at offset 270299136. GEOM_ELI: da5.eli: Failed to authenticate 65536 bytes of data at offset 270319616. GEOM_ELI: da5.eli: Failed to authenticate 5792 bytes of data at offset 273095488. GEOM_ELI: da5.eli: Failed to authenticate 56864 bytes of data at offset 273105376. GEOM_ELI: da5.eli: Failed to authenticate 2400 bytes of data at offset 273326080. GEOM_ELI: da5.eli: Failed to authenticate 65536 bytes of data at offset 272560128. GEOM_ELI: da5.eli: Failed to authenticate 131072 bytes of data at offset 272429056. GEOM_ELI: da5.eli: Failed to authenticate 32768 bytes of data at offset 272396288. ___ 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: deadlock between g_event and a thread on removing a device.
Hi Konstantin,
Thank you for your comment.
I don't have any solution for this issue.
And when a device is removed suddenly, there are other problems, I think.
> On Fri, Jan 18, 2013 at 02:45:38PM +0900, Kohji Okuno wrote:
>> Hi,
>>
>> When I removed a device (ex. /dev/da0), I have encounterd a
>> dead-lock between ``g_event'' thread and a thread that is opening
>> device file (I call this thread as A).
>>
>> Would you refer the following?
>>
>> When the device is removed between dev_refthread() and g_dev_open(),
>> thread A incremented dev->si_threadcount, but can't acquire
>> topology_lock.
>>
>> On the other hand, g_event is waiting to set dev->si_threadcount to 0
>> with topology_lock.
>>
>> Regards,
>> Kohji Okuno
>>
>>
>> <<< Thread A >>>
>> ...
>> devfs_open()
>> {
>> ...
>> dsw = dev_refthread(dev, &ref); <= increment dev->si_threadcount
>> ...
>> error = dsw->d_open(...); <= call g_dev_open()
>> ...
>> dev_relthread(dev, ref);<= decrement dev->si_threadcount
>> }
>>
>> g_dev_open()
>> {
>> ...
>> g_topology_lock(); <= Thread A couldn't acquire
>> ...topology_lock.
>> }
>>
>> <<< g_event >>>
>> g_run_events()
>> {
>>...
>>g_topology_lock(); <= g_event acuired topology_lock here.
>>...
>>one_event()
>>...
>> }
>>
>> one_event()
>> g_orphan_register()
>> g_dev_orphan()
>> destroy_dev()
>> destroy_dev()
>> destroy_devl()
>> {
>> ...
>> while (dev->si_threadcount != 0) { <= this count was incremented by Thread
>> A
>> /* Use unique dummy wait ident */
>> msleep(&csw, &devmtx, PRIBIO, "devdrn", hz / 10);
>> }
>> ...
>> }
>
> Yes, you are absolutely right.
>
> I believe there were some patches floating around which changed the
> destroy_dev() call in the g_dev_orphan() to destroy_dev_sched(). I do
> not remember who was the author.
>
> My reply was that naive substitution of the destroy_dev() to
> destroy_dev_sched() is racy, because some requests might still come
> in after the call to destroy_dev_sched(). Despite destroy_dev_sched()
> setting the CDP_SCHED_DTR flag on the devfs node, some thread might
> already entered the cdevsw method. I do not believe that there was
> further progress there.
___
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: deadlock between g_event and a thread on removing a device.
On Fri, Jan 18, 2013 at 02:45:38PM +0900, Kohji Okuno wrote:
> Hi,
>
> When I removed a device (ex. /dev/da0), I have encounterd a
> dead-lock between ``g_event'' thread and a thread that is opening
> device file (I call this thread as A).
>
> Would you refer the following?
>
> When the device is removed between dev_refthread() and g_dev_open(),
> thread A incremented dev->si_threadcount, but can't acquire
> topology_lock.
>
> On the other hand, g_event is waiting to set dev->si_threadcount to 0
> with topology_lock.
>
> Regards,
> Kohji Okuno
>
>
> <<< Thread A >>>
> ...
> devfs_open()
> {
> ...
> dsw = dev_refthread(dev, &ref); <= increment dev->si_threadcount
> ...
> error = dsw->d_open(...); <= call g_dev_open()
> ...
> dev_relthread(dev, ref);<= decrement dev->si_threadcount
> }
>
> g_dev_open()
> {
> ...
> g_topology_lock(); <= Thread A couldn't acquire
> ...topology_lock.
> }
>
> <<< g_event >>>
> g_run_events()
> {
>...
>g_topology_lock(); <= g_event acuired topology_lock here.
>...
>one_event()
>...
> }
>
> one_event()
> g_orphan_register()
> g_dev_orphan()
> destroy_dev()
> destroy_dev()
> destroy_devl()
> {
> ...
> while (dev->si_threadcount != 0) { <= this count was incremented by Thread A
> /* Use unique dummy wait ident */
> msleep(&csw, &devmtx, PRIBIO, "devdrn", hz / 10);
> }
> ...
> }
Yes, you are absolutely right.
I believe there were some patches floating around which changed the
destroy_dev() call in the g_dev_orphan() to destroy_dev_sched(). I do
not remember who was the author.
My reply was that naive substitution of the destroy_dev() to
destroy_dev_sched() is racy, because some requests might still come
in after the call to destroy_dev_sched(). Despite destroy_dev_sched()
setting the CDP_SCHED_DTR flag on the devfs node, some thread might
already entered the cdevsw method. I do not believe that there was
further progress there.
pgp1qBkOqiqiE.pgp
Description: PGP signature
Re: r245838: make world fails: /usr/src/usr.bin/dtc/dtc.cc:196:24: error: use of undeclared identifier 'optarg', string arg = string(optarg);
This appears to be caused by your addition of -stdlib=libc++ -std=c++11 to
your CXXFLAGS. So, first of all, thank you for testing libc++!
I tested with libc++ while I was developing dtc, but then was building with
libstdc++ while I was removing extraneous includes. Unfortunately, libstdc++
leaks a load of C headers, whereas libc++ is very careful not to. I've now
(r245839) explicitly included everything so it now builds with libc++ and in
C++11 mode.
Thanks for the report,
David
On 23 Jan 2013, at 08:15, O. Hartmann wrote:
> Make world fails in /usr/src/usr.bin/dtc/dtc.cc with a lot of errors
> com[laining about an undeclared identifier:
>
> [...]
> ===> usr.bin/dtc (obj,depend,all,install)
> /usr/obj/usr/src/tmp/usr/src/usr.bin/dtc created for /usr/src/usr.bin/dtc
> rm -f .depend
> mkdep -f .depend -a-I/usr/obj/usr/src/tmp/legacy/usr/include
> -std=c++11 -stdlib=libc++ /usr/src/usr.bin/dtc/dtc.cc
> /usr/src/usr.bin/dtc/input_buffer.cc /usr/src/usr.bin/dtc/string.cc
> /usr/src/usr.bin/dtc/dtb.cc /usr/src/usr.bin/dtc/fdt.cc
> /usr/src/usr.bin/dtc/checking.cc
> echo dtc: /usr/lib/libc.a /usr/obj/usr/src/tmp/legacy/usr/lib/libegacy.a
>>> .depend
> echo dtc: /usr/lib/libc++.a >> .depend
> c++ -O2 -pipe -O3 -I/usr/obj/usr/src/tmp/legacy/usr/include
> -stdlib=libc++ -std=c++11 -c /usr/src/usr.bin/dtc/dtc.cc
> c++ -O2 -pipe -O3 -I/usr/obj/usr/src/tmp/legacy/usr/include
> -stdlib=libc++ -std=c++11 -c /usr/src/usr.bin/dtc/input_buffer.cc
> /usr/src/usr.bin/dtc/input_buffer.cc:116:11: error: use of undeclared
> identifier 'strtoll'
> [...]
> 7 errors generated.
> *** [string.o] Error code 1
> /usr/src/usr.bin/dtc/input_buffer.cc:218:10: error: use of undeclared
> identifier 'stderr'
>fprintf(stderr, "Current cursor: %d\n", cursor);
>^
> /usr/src/usr.bin/dtc/input_buffer.cc:219:42: error: use of undeclared
> identifier 'stderr'
>fwrite(&buffer[cursor], size-cursor, 1, stderr);
>^
> /usr/src/usr.bin/dtc/input_buffer.cc:227:3: error: use of undeclared
> identifier 'perror'
>perror("Failed to stat file");
>^
> /usr/src/usr.bin/dtc/input_buffer.cc:234:3: error: use of undeclared
> identifier 'perror'
>perror("Failed to mmap file");
>^
> /usr/src/usr.bin/dtc/input_buffer.cc:249:20: error: use of undeclared
> identifier 'stdin'
>while ((c = fgetc(stdin)) != EOF)
> ^
> /usr/src/usr.bin/dtc/input_buffer.cc:249:31: error: use of undeclared
> identifier 'EOF'
>while ((c = fgetc(stdin)) != EOF)
> ^
> 15 errors generated.
> *** [input_buffer.o] Error code 1
> /usr/src/usr.bin/dtc/dtb.cc:87:2: error: use of undeclared identifier
> 'write'
>write(fd, buffer.data(), buffer.size());
>^
> /usr/src/usr.bin/dtc/dtb.cc:125:2: error: use of undeclared identifier
> 'snprintf'; did you mean 'vswprintf'?
>snprintf(out, 3, "%.2hhx", b);
>^~~~
>vswprintf
> /usr/include/wchar.h:130:5: note: 'vswprintf' declared here
> int vswprintf(wchar_t * __restrict, size_t n, const wchar_t *
> __restrict,
>^
> /usr/src/usr.bin/dtc/dtb.cc:125:11: error: cannot initialize a parameter
> of type 'wchar_t *' with an lvalue of type 'char [3]'
>snprintf(out, 3, "%.2hhx", b);
> ^~~
> /usr/include/wchar.h:130:35: note: passing argument to parameter here
> int vswprintf(wchar_t * __restrict, size_t n, const wchar_t *
> __restrict,
> ^
> /usr/src/usr.bin/dtc/dtb.cc:218:2: error: use of undeclared identifier
> 'write'
>write(fd, buffer.data(), buffer.size());
>^
> /usr/src/usr.bin/dtc/dtb.cc:259:11: error: use of undeclared identifier
> 'stderr'
>fprintf(stderr, "Missing magic token in header. Got %"
> PRIx32
>^
> 5 errors generated.
> *** [dtb.o] Error code 1
> /usr/src/usr.bin/dtc/dtc.cc:102:15: error: use of undeclared identifier
> 'getopt'
>while ((ch = getopt(argc, argv, options)) != -1)
> [...]
>
signature.asc
Description: Message signed with OpenPGP using GPGMail
r245838: make world fails: /usr/src/usr.bin/dtc/dtc.cc:196:24: error: use of undeclared identifier 'optarg', string arg = string(optarg);
Make world fails in /usr/src/usr.bin/dtc/dtc.cc with a lot of errors
com[laining about an undeclared identifier:
[...]
===> usr.bin/dtc (obj,depend,all,install)
/usr/obj/usr/src/tmp/usr/src/usr.bin/dtc created for /usr/src/usr.bin/dtc
rm -f .depend
mkdep -f .depend -a-I/usr/obj/usr/src/tmp/legacy/usr/include
-std=c++11 -stdlib=libc++ /usr/src/usr.bin/dtc/dtc.cc
/usr/src/usr.bin/dtc/input_buffer.cc /usr/src/usr.bin/dtc/string.cc
/usr/src/usr.bin/dtc/dtb.cc /usr/src/usr.bin/dtc/fdt.cc
/usr/src/usr.bin/dtc/checking.cc
echo dtc: /usr/lib/libc.a /usr/obj/usr/src/tmp/legacy/usr/lib/libegacy.a
>> .depend
echo dtc: /usr/lib/libc++.a >> .depend
c++ -O2 -pipe -O3 -I/usr/obj/usr/src/tmp/legacy/usr/include
-stdlib=libc++ -std=c++11 -c /usr/src/usr.bin/dtc/dtc.cc
c++ -O2 -pipe -O3 -I/usr/obj/usr/src/tmp/legacy/usr/include
-stdlib=libc++ -std=c++11 -c /usr/src/usr.bin/dtc/input_buffer.cc
/usr/src/usr.bin/dtc/input_buffer.cc:116:11: error: use of undeclared
identifier 'strtoll'
[...]
7 errors generated.
*** [string.o] Error code 1
/usr/src/usr.bin/dtc/input_buffer.cc:218:10: error: use of undeclared
identifier 'stderr'
fprintf(stderr, "Current cursor: %d\n", cursor);
^
/usr/src/usr.bin/dtc/input_buffer.cc:219:42: error: use of undeclared
identifier 'stderr'
fwrite(&buffer[cursor], size-cursor, 1, stderr);
^
/usr/src/usr.bin/dtc/input_buffer.cc:227:3: error: use of undeclared
identifier 'perror'
perror("Failed to stat file");
^
/usr/src/usr.bin/dtc/input_buffer.cc:234:3: error: use of undeclared
identifier 'perror'
perror("Failed to mmap file");
^
/usr/src/usr.bin/dtc/input_buffer.cc:249:20: error: use of undeclared
identifier 'stdin'
while ((c = fgetc(stdin)) != EOF)
^
/usr/src/usr.bin/dtc/input_buffer.cc:249:31: error: use of undeclared
identifier 'EOF'
while ((c = fgetc(stdin)) != EOF)
^
15 errors generated.
*** [input_buffer.o] Error code 1
/usr/src/usr.bin/dtc/dtb.cc:87:2: error: use of undeclared identifier
'write'
write(fd, buffer.data(), buffer.size());
^
/usr/src/usr.bin/dtc/dtb.cc:125:2: error: use of undeclared identifier
'snprintf'; did you mean 'vswprintf'?
snprintf(out, 3, "%.2hhx", b);
^~~~
vswprintf
/usr/include/wchar.h:130:5: note: 'vswprintf' declared here
int vswprintf(wchar_t * __restrict, size_t n, const wchar_t *
__restrict,
^
/usr/src/usr.bin/dtc/dtb.cc:125:11: error: cannot initialize a parameter
of type 'wchar_t *' with an lvalue of type 'char [3]'
snprintf(out, 3, "%.2hhx", b);
^~~
/usr/include/wchar.h:130:35: note: passing argument to parameter here
int vswprintf(wchar_t * __restrict, size_t n, const wchar_t *
__restrict,
^
/usr/src/usr.bin/dtc/dtb.cc:218:2: error: use of undeclared identifier
'write'
write(fd, buffer.data(), buffer.size());
^
/usr/src/usr.bin/dtc/dtb.cc:259:11: error: use of undeclared identifier
'stderr'
fprintf(stderr, "Missing magic token in header. Got %"
PRIx32
^
5 errors generated.
*** [dtb.o] Error code 1
/usr/src/usr.bin/dtc/dtc.cc:102:15: error: use of undeclared identifier
'getopt'
while ((ch = getopt(argc, argv, options)) != -1)
[...]
signature.asc
Description: OpenPGP digital signature
Compilation error (pkgng)
Seems this check-in causing compilation error:
http://freshbsd.org/commit/freebsd/r245828
-nonliteral -c /usr/src/usr.sbin/pkg_install/lib/pkgng.c -o pkgng.o
/usr/src/usr.sbin/pkg_install/lib/pkgng.c:53:45: error: expected ')'
rc = snprintf(pkgngpath, sizeof(pkgngpath) "%s/local.sqlite",
pkgngdir);
^
/usr/src/usr.sbin/pkg_install/lib/pkgng.c:53:15: note: to match this '('
rc = snprintf(pkgngpath, sizeof(pkgngpath) "%s/local.sqlite",
pkgngdir);
^
/usr/src/usr.sbin/pkg_install/lib/pkgng.c:54:9: warning: comparison of
integers of different signs: 'int' and 'unsigned int' [-Wsign-compare]
if (rc >= sizeof(pkgngpath)) {
~~ ^ ~
1 warning and 1 error generated.
*** [pkgng.o] Error code 1
Stop in /usr/src/usr.sbin/pkg_install/lib.
*** [all] Error code 1
Stop in /usr/src/usr.sbin/pkg_install.
*** [all] Error code 1
Stop in /usr/src/usr.sbin.
*** [usr.sbin.all__D] Error code 1
Stop in /usr/src.
*** [everything] Error code 1
Stop in /usr/src.
*** [buildworld] Error code 1
Stop in /usr/src.
___
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: kmem_map auto-sizing and size dependencies
On 23.01.2013 00:22, Artem Belevich wrote: On Mon, Jan 21, 2013 at 1:06 PM, Pawel Jakub Dawidek wrote: On Fri, Jan 18, 2013 at 08:26:04AM -0800, m...@freebsd.org wrote: Should it be set to a larger initial value based on min(physical,KVM) space available? It needs to be smaller than the physical space, [...] Or larger, as the address space can get fragmented and you might not be able to allocate memory even if you have physical pages available. +1 for relaxing upper limit. I routinely patch all my systems that use ZFS to allow kmem_map size to be larger than physical memory. Otherwise on a system where most of RAM goes towards ZFS ARC I used to eventually run into dreaded kmem_map too small panic. During startup and VM initialization the following kernel VM maps are created: kernel_map (parent) specifying the entire kernel virtual address space. It is 512GB on amd64 currently. Out of the kernel_map a number of sub-maps are created: clean_map which isn't referenced anywhere else buffer_map used in vfs_bio.c for i/o buffers pager_map used in vm_page.c for paging exec_map used in kern/kern_exec.c and other places for program startup pipe_map used in kern/sys_pipe.c for pipe buffering kmem_map used in kern/kern_malloc. and vm/uma_core.c among other places and provides all kernel malloc and UMA zone memory allocations. Having the kernel occupy all of physical RAM eventually isn't pretty. So the problem you're describing is that even though enough kernel_map space is still available it is too fragmented to find a sufficiently large chunk. If the kmem_map is larger than the available physical memory another mechanism has to track and limit its physical memory consumption. This may become a SMP bottleneck due to synchronization issues. I haven't looked how the maps are managed internally. Maybe there is a natural hook to attach such a mechanism and to allow the sub-maps to be larger in kVM space than physical memory. Maybe ZFS then can have its own sub-map for ARC too. -- Andre ___ 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"
