Re: [CFT]hwpmc update for sandybridge-e
Le 5 oct. 2012 à 00:46, Sean Bruno a écrit : So, I did the bear minimum and kind of hacked things together without understanding precisely what I was doing, and I was able to massage the sandybridge-e CPUs into giving me some basic functions. Comments or concerns before I commit this? http://people.freebsd.org/~sbruno/pmc_sandybridge.txt Hi Sean, The only modification required is this one http://svnweb.freebsd.org/base?view=revisionrevision=237196 but davide@ removed it for a problem that need to be looked at. Fabien Sean p.s. I'm trying to hunt down some IvyBridge boxes to finish this off. ___ 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: [CFT]hwpmc update for sandybridge-e
Le 5 oct. 2012 à 10:00, Fabien Thomas a écrit : Le 5 oct. 2012 à 00:46, Sean Bruno a écrit : So, I did the bear minimum and kind of hacked things together without understanding precisely what I was doing, and I was able to massage the sandybridge-e CPUs into giving me some basic functions. Comments or concerns before I commit this? http://people.freebsd.org/~sbruno/pmc_sandybridge.txt Hi Sean, The only modification required is this one http://svnweb.freebsd.org/base?view=revisionrevision=237196 but davide@ removed it for a problem that need to be looked at. Looking at the doc this CPU require a full set of PMC as the list of event are different. So this mean full manpage, full event list, … Doc: The events in Table 19-3 apply to processors with CPUID signature of DisplayFamily_DisplayModel encoding with the following values: 06_2AH and 06_2DH. The events in Table 19-4 apply to processors with CPUID signature 06_2AH. The events in Table 19-5 apply to processors with CPUID signature 06_2DH. Required change will be the same as this commit if you want to look at it: http://svnweb.freebsd.org/base?view=revisionrevision=240164 Fabien Sean p.s. I'm trying to hunt down some IvyBridge boxes to finish this off. ___ 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: [HEADSUP] Upcoming GNU sort removal
04.10.2012 13:53, Gabor Kovesdan wrote: it has been more than 3 months ago that BSD sort became default in HEAD and no serious complaints have been raised against it since then so I plan to permanently remove GNU sort from head in the next days. If you have any objection, please raise it now. http://scan.freebsd.your.org/freebsd-head/usr.bin.grep/2012-01-12-amd64/ /usr/src/usr.bin/grep/regex/xmalloc.c:341:7: warning: Use of memory after it is freed hash_table_del(xmalloc_table, ptr); ^ ~~~ 1 warning generated. /usr/src/usr.bin/grep/regex/tre-fastmatch.c:534:3: warning: Result of 'malloc' is converted to a pointer of type 'unsigned int', which is incompatible with sizeof operand type 'int' FILL_BMGS; ^ /usr/src/usr.bin/grep/regex/tre-fastmatch.c:343:19: note: expanded from macro 'FILL_BMGS' fg-sbmGs = xmalloc(fg-len * sizeof(int)); \ ^ /usr/src/usr.bin/grep/regex/xmalloc.h:69:23: note: expanded from macro 'xmalloc' #define xmalloc(size) malloc(size) ^~ /usr/src/usr.bin/grep/regex/tre-fastmatch.c:537:3: warning: Result of 'malloc' is converted to a pointer of type 'unsigned int', which is incompatible with sizeof operand type 'int' FILL_BMGS_WIDE; ^~ /usr/src/usr.bin/grep/regex/tre-fastmatch.c:359:18: note: expanded from macro 'FILL_BMGS_WIDE' fg-bmGs = xmalloc(fg-wlen * sizeof(int)); \ ^ /usr/src/usr.bin/grep/regex/xmalloc.h:69:23: note: expanded from macro 'xmalloc' #define xmalloc(size) malloc(size) ^~ /usr/src/usr.bin/grep/regex/tre-fastmatch.c:707:3: warning: Memory is never released; potential leak of memory pointed to by 'tmp' STORE_MBS_PAT; ^ /usr/src/usr.bin/grep/regex/tre-fastmatch.c:97:14: note: expanded from macro 'STORE_MBS_PAT' return REG_ESPACE;\ ^~ /usr/src/usr.bin/grep/regex/tre-fastmatch.c:766:3: warning: Result of 'malloc' is converted to a pointer of type 'unsigned int', which is incompatible with sizeof operand type 'int' FILL_BMGS; ^ /usr/src/usr.bin/grep/regex/tre-fastmatch.c:343:19: note: expanded from macro 'FILL_BMGS' fg-sbmGs = xmalloc(fg-len * sizeof(int)); \ ^ /usr/src/usr.bin/grep/regex/xmalloc.h:69:23: note: expanded from macro 'xmalloc' #define xmalloc(size) malloc(size) ^~ /usr/src/usr.bin/grep/regex/tre-fastmatch.c:769:3: warning: Result of 'malloc' is converted to a pointer of type 'unsigned int', which is incompatible with sizeof operand type 'int' FILL_BMGS_WIDE; ^~ /usr/src/usr.bin/grep/regex/tre-fastmatch.c:359:18: note: expanded from macro 'FILL_BMGS_WIDE' fg-bmGs = xmalloc(fg-wlen * sizeof(int)); \ ^ /usr/src/usr.bin/grep/regex/xmalloc.h:69:23: note: expanded from macro 'xmalloc' #define xmalloc(size) malloc(size) ^~ 5 warnings generated. How about fixing http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/167921 ? /usr/bin/grep /tmp/ports/.amd_mnt/faz/host/usr/ports/textproc/docbook-410/work/\\. Segmentation fault (core dumped) uname -a FreeBSD ar1l0u 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #0 r241156M: Wed Oct 3 13:58:16 EEST 2012 arcade@ar1l0u:/usr/obj/usr/src/sys/MINIMAL amd64 gdb /usr/obj/usr/src/usr.bin/grep/grep grep.core GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as amd64-marcel-freebsd...(no debugging symbols found)... Core was generated by `grep'. Program terminated with signal 11, Segmentation fault. Reading symbols from /lib/libz.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/libz.so.6 Reading symbols from /usr/lib/liblzma.so.5...(no debugging symbols found)...done. Loaded symbols for /usr/lib/liblzma.so.5 Reading symbols from /usr/lib/libbz2.so.4...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libbz2.so.4 Reading symbols from /usr/lib/libgnuregex.so.5...(no debugging symbols found)...done. Loaded symbols for /usr/lib/libgnuregex.so.5 Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x004069d2 in tre_compile_fast () (gdb) bt full #0 0x004069d2 in tre_compile_fast () No symbol table info available. #1 0x00404d06 in tre_fastncomp () No symbol table
Re: memory warnings r240891 | dmesg
(30) @ 12:01:50 swapinfo Device 1K-blocks UsedAvail Capacity /dev/zvol/bigD/swap 41943040 4194304 0% /dev/gpt/swap0.eli 31457280 3145728 0% /dev/gpt/swap1.eli 31457280 3145728 0% Total104857600 10485760 0% [...] * FreeBSD 10.0-CURRENT #1 r240891: Tue Sep 25 00:51:03 EDT 2012 warning: increase kern.maxswzone or reduce amount of swap. * Apparently kern.maxswzone is currently equal to 0. How might I tweak it just enough to fix this? So, reduce amount of swap :) This is because kernel needs some memory to manage swap too. Currently for amd64 this roughly reduces to the following rule (My apologies in advance for the extra simplification): 100MB RAM per 800MB swap space. So, with your current amount of RAM (893MB) it is recommended to setup no more than 7144 MB of swap. [1] Thanks for the good ideas. Thus far, # zfs get volsize bigD/swap NAME PROPERTY VALUESOURCE bigD/swap volsize 4G local # zfs set volsize=1100m bigD/swap # zfs get volsize bigD/swap NAME PROPERTY VALUESOURCE bigD/swap volsize 1.07Glocal (73) @ 6:55:44 swapinfo -h Device 1K-blocks UsedAvail Capacity /dev/#C:0x6c 4194304 808k 4G 0% /dev/gpt/swap0.eli 3145728 772k 3G 0% /dev/gpt/swap1.eli 3145728 800k 3G 0% Total10485760 2.3M 10G 0% - yes, it appeared that something weird happened to the file name # zfs destroy -V bigD/swap - file in use or some error # reboot # swapinfo -h Device 1K-blocks UsedAvail Capacity /dev/zvol/bigD/swap 1126400 0B 1.1G 0% /dev/gpt/swap0.eli 3145728 0B 3.0G 0% /dev/gpt/swap1.eli 3145728 0B 3.0G 0% Total 7417856 0B 7.1G 0% So the zvol swap size was reduced, but the swzone error still exists. Also, the zfs create and destroy commands availed nothing- perhaps there were subsequent or subcommands to run there. Is there a good method to reduce the encrypted swap, perhaps? I might like to have a total of 3g encrypted swap plus 3g zvol swap. Darrel ___ 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: sysctl kern.ipc.somaxconn limit 65535 why?
On 03/10/2012 22:15, Andre Oppermann wrote: I guess the problem is rather kern.ipc.maxsockets which is only 25600. maxsockets should be bumped up quite a bit by default IMO. How far needs some analysis because there are some dependencies and memory requirements. So, how about a heuristic, 20,000 + (5000 for every GB of RAM)? A small, 16 GB machine (yes, 16 GB is small nowadays) would have 100,000, which should be enough. signature.asc Description: OpenPGP digital signature
FreeBSD 10-CURRENT and 9-STABLE snapshots
Hi, A number of FreeBSD users have displayed interest in the availability and testing of -STABLE and -CURRENT snapshot releases. I have been working on generating snapshots regularly, and now would like to announce their availability for those interested in testing. Please note, as always with the -STABLE and -CURRENT branches, these snapshots are not intended for production systems. The snapshots available are: - 10.0-CURRENT amd64 - 10.0-CURRENT i386 - 9.1-PRERELEASE amd64 - 9.1-PRERELEASE i386 Note that the 9.1-PRERELEASE snapshots are the stable/9 branch, not what will eventually be 9.1-RELEASE. I do not yet have snapshots for the 8-STABLE branch, but am working on the magic to make that happen as well. There are also no bootonly ISOs, since the necessary distribution sets are not available on the FreeBSD FTP servers, so I cannot direct the installer to a different location very easily. The URL for the snapshots is: https://snapshots.glenbarber.us/Latest/ The SHA256 of the xz(1)-compressed install medium follows, and is also included in a plain-text file on the site. FreeBSD-10.0-CURRENT-amd64-memstick.xz = 8779f5925cb903c64d647392f6af825d5e74019d6d13222045d69091b03a81ff FreeBSD-10.0-CURRENT-amd64-release.iso.xz = cc3934c947563c23f92ba1cd8ca7ded3999dfbc050e2b2647c294e442f267040 FreeBSD-10.0-CURRENT-i386-memstick.xz = 9eb7ff8e28c0c524d2794828acb601b9b7079c1d00017e3bf84b974ff4412e42 FreeBSD-10.0-CURRENT-i386-release.iso.xz = 0d1334fea13e16cb0d06a3f3c3fb7b0e1223baf06a06a889a6cffa6981348ae5 FreeBSD-9.1-PRERELEASE-amd64-memstick.xz = f5f1e7acbaaac6eb61c5194199eb6ef090af242efc9808dc1af5caeee126e15e FreeBSD-9.1-PRERELEASE-amd64-release.iso.xz = 0cfa5b258428741e0345b29eed241188d5944fcb15a70b079d39d56195f0 FreeBSD-9.1-PRERELEASE-i386-memstick.xz = 4e98ffe63b186b0e26f22c3ddfb0582019bf352d1ea39da2757817c809872b67 FreeBSD-9.1-PRERELEASE-i386-release.iso.xz = 0bce6f2a9626705484ff7cac18623f714e289ef6ddc0b6199d78eba37ded2ca4 The Latest directory on the site will always point to the latest batch of snapshots, which right now my goal is to regenerate every few days (I do not have a definitive timeframe in mind yet). I hope these are useful to the FreeBSD community. Feedback on this is welcome, as always. Cheers, Glen PS: Please report any issues regarding downloading to me directly. pgptJCC1nzjIf.pgp Description: PGP signature
Re: sysctl kern.ipc.somaxconn limit 65535 why?
On 5 October 2012 05:26, Ivan Voras ivo...@freebsd.org wrote: On 03/10/2012 22:15, Andre Oppermann wrote: I guess the problem is rather kern.ipc.maxsockets which is only 25600. maxsockets should be bumped up quite a bit by default IMO. How far needs some analysis because there are some dependencies and memory requirements. So, how about a heuristic, 20,000 + (5000 for every GB of RAM)? A small, 16 GB machine (yes, 16 GB is small nowadays) would have 100,000, which should be enough. Well, it depends on what the server is being used for, right? If it's a small object proxy/web server sure. But if it's a streaming server you may only need a few thousand sockets but very deep send buffers. Honestly, I'd really like the OP to come to us with workloads that aren't working and get them fixed. We're a pretty smart bunch over here and it's highly likely that both he and we would learn from the process. :) And double honestly, it may be nice to print out a running out of sockets! warning, as well as a running out of mbufs! warning. Rate limited, so people don't get spammed. But a gentle notification that they should retune some stuff would be user-friendly. Adrian ___ 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: [HEADSUP] Upcoming GNU sort removal
05.10.2012 13:57, Volodymyr Kostyrko wrote: 04.10.2012 13:53, Gabor Kovesdan wrote: it has been more than 3 months ago that BSD sort became default in HEAD and no serious complaints have been raised against it since then so I plan to permanently remove GNU sort from head in the next days. If you have any objection, please raise it now. http://scan.freebsd.your.org/freebsd-head/usr.bin.grep/2012-01-12-amd64/ Please excuse me for this, I misread the subject. -- Sphinx of black quartz, judge my vow. ___ 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: FreeBSD 10-CURRENT and 9-STABLE snapshots
Glen Barber wrote: Hi, A number of FreeBSD users have displayed interest in the availability and testing of -STABLE and -CURRENT snapshot releases. I have been working on generating snapshots regularly, and now would like to announce their availability for those interested in testing. Please note, as always with the -STABLE and -CURRENT branches, these snapshots are not intended for production systems. The snapshots available are: - 10.0-CURRENT amd64 - 10.0-CURRENT i386 - 9.1-PRERELEASE amd64 - 9.1-PRERELEASE i386 Note that the 9.1-PRERELEASE snapshots are the stable/9 branch, not what will eventually be 9.1-RELEASE. I do not yet have snapshots for the 8-STABLE branch, but am working on the magic to make that happen as well. There are also no bootonly ISOs, since the necessary distribution sets are not available on the FreeBSD FTP servers, so I cannot direct the installer to a different location very easily. The URL for the snapshots is: https://snapshots.glenbarber.us/Latest/ It would be nice to have them hosted on FreeBSD.org site as official source. Unofficial snapshots can be downloaded from https://pub.allbsd.org/FreeBSD-snapshots/ for a long time (bootonly.iso too) Miroslav Lachman ___ 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: svn MFC to stable/8
On Thursday, October 04, 2012 6:06:56 pm Rick Macklem wrote: John Baldwin wrote: On Thursday, October 04, 2012 2:10:11 pm Rick Macklem wrote: Hi, Hopefully someone familiar with svn can help. When I try to MFC a kernel change to stable/8, it works, but I end up with tons of mergeinfo. (It looks like every directory under sys.) Does this matter or is there a trick to avoid this? Thanks in advance for any help, rick ps: I seem to MFC fine to stable/9. I only see this for stable/8. Someone screwed up the mergeinfo on stable/8/sys/dev due to svn 1.6 not working well with newer merges from 1.7. The simplest solution is to just update your client to svn 1.7. Otherwise, you can commit what you have now with 1.6. Thanks yet again John. I used svn1.7 and it didn't have all the dirs. It only listed directory properties for sys and sys/fs, which I hope was ok, since I committed it. Yep. -- John Baldwin ___ 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: sysctl kern.ipc.somaxconn limit 65535 why?
On Fri, Oct 05, 2012 at 08:21:53AM +1000, Peter Jeremy wrote: On 2012-Oct-03 19:45:01 +0100, free...@chrysalisnet.org wrote: In addition we had to migrate all our mysql servers from freebsd to debian because they were hitting some arbitary OS limit but I could never figure out what, sys% usage went through the roof when this limit was hit, issue didnt occur on debian. It's a well known point that linux isn't serving time correctly where FreeBSD requires much more load to do it right. It is also well known that MySQL asks for time horrible often. Don't know what they expect this to serve, when it's either slow or wrong, but they do it. Maybe we have hacked around this issue - there are lots of people doing workload tests comparing Databases on Linux and FreeBSD and in the end it always is more or less equal when everything is configured right. Our installed defaults for MySQL migh be different than with Debian and also OS tuning is very different. Sometimes even hardware selection can make big difference when comparing OS, if one OS has a slow driver for a given hardware, or one has a lazy driver ignoring data consistency. Did you report this issue on any of the FreeBSD mailing lists? Reporting a problem doesn't guarantee that it will be fixed (unfortunately) but not reporting a problem makes it extremely unlikely that it will be fixed. I feel recently freebsd is more focused on desktop's and as such developer's never develop for a heavy server usage scenario, This isn't intentionally true but it's true that few developers run large servers so they may not run into some issues that only impact large systems. Again, it's up to people who do run such systems to provide feedback about bottlenecks issues they hit so that they can be fixed. I keep coming across hardcoded low limits. As rightly pointed out default There are lots of defaults that were set some time (potentially decades) ago and may no longer be optimal. It's unrealistic to expect that all the defaults are correct in all circumstances and this is one area where end users can help by flagging defaults that they find need tuning. values now days are useless 128 for somaxconn? maybe ok for a desktop. But, as others have pointed out, this isn't one of them. Can you please provide more details on a use scenario where a listen(2) backlog exceeding 128 is reasonable. It's simple math. If the accept loop sleeps for 1 second a connection backlog of 128 ist good for 128 connections per second. However accept loops sleeping for 1 second for high rate servers mean there is something programmed wrong - more likely accept loops sleep for 1-5ms, so 128 is good for at least 25600 connetions per second. Requiring more than 65536 with well done programming means that you try to handle more than 13107200 connections per second. Such a connection rate sounds even unlikely given the number of IP packets required on the network interface just to establish the connections. Furthermore - the typical high transaction service these days are webservers and there you can benefit from keepalive very much. If on the other hand your well written accept loop isn't fast enough because of high CPU load, then the machine is simply overloaded and queuing more connections won't serve you anything but changing symptoms. In any case it ends in bad programming or extremly untypical use case. Yes - we do not support bad programmed applications or every imaginable extreme use case out of the box, that's right. -- B.Walter be...@bwct.de http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. ___ 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: FreeBSD 10-CURRENT and 9-STABLE snapshots
On 05/10/2012 15:29, Miroslav Lachman wrote: Unofficial snapshots can be downloaded from https://pub.allbsd.org/FreeBSD-snapshots/ for a long time (bootonly.iso too) I'm baffled as to why those aren't just made official. -- Bruce Cran ___ 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
