Re: CURRENT as gateway on not-so-fast hardware: where is a bottlneck?
On Fri, Aug 17, 2012 at 3:23 PM, Ian Lepore free...@damnhippie.dyndns.org wrote: On Fri, 2012-08-17 at 14:29 -0700, Kevin Oberman wrote: On Fri, Aug 17, 2012 at 10:11 AM, Ian Lepore No! Not bde! He'll notice that I violated style(9) by accidentally leaving an extra blank line between a comment block and the function definition. :) (There are probably more violations than that -- I did this when I was first trying to come to grips with the differences between style(9) and the almost-style(9) standards we use at work.) When I first proposed the changes, jhb remarked that they sounded good, but as far as I know, nobody reviewed the actual diff when I posted it. It looks like bde and phk were the primary maintainers back when this code was being more actively worked on. Why not bde? Everyone needs to learn what the term bruceification means. Believe me, there IS good reason for programming style and almost everyone with a commit bit gets close. bde will provide a reminder of any of those things you forgot were in style(9). This is something we should appreciate, even if it does sting a bit. Did you miss the smiley I buried between two sentences there? Having worked on code written with no style guidelines, I totally understand the need for consistent style. While I find a couple of style(9)'s edicts to be massively annoying, all in all I'd rather work on code that has a consistent style I hate than on code with no consistency. Nope. I didn't miss it, but you missed the one I neglected to type at the end of the first line in my message. I really appreciate all that he does including being the foremost style(9) checker. Besides, many of the newer folks around here may not understand just what bruceification is. Only those whose code has not caught his attention, though. :-) (I remembered, this time) -- 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: HELP! core dumps: install, mtree, et cetera all of the sudden after portmaster security/cyrus-sasl2
Am 08/16/12 21:44, schrieb Garrett Cooper: On Thu, Aug 16, 2012 at 8:33 AM, Hartmann, O. ohart...@zedat.fu-berlin.de wrote: I ran into a very delicate and nasty situation. ... On both FBSD 10 boxes, the installation of the port security/cyrus-sasl2 got corrupted by install and/or mtree dumping core and signalling SIGNAL 11. Booting into multiuser mode is impossible, login core dumps SIGNAL 11, many other daemons, too. The only way is to boot into single user mode. I'm not drawing a correlation between this and unrelated coredumping processes. Me neither, I report this for completeness, since I'm not a OS developer, such a behaviour could hint/indicate people who are involved in the OS development, what is going on. Sorry when I'm trying to be too precise (precise as precise I can be without the exact terminology!). An installation failed due to pkg(ng) was missing libarchive.so via portmaster or via core dumping install(1). By installing on one box, my home box, port security/cyrus-sasl2 manually, luckily install(1) and mtree(1) didn't coredump and it worked - and this precedure rescued me. But on my lab's development box, it doesn't work! Don't make delete-old-lib unless you have it moved off to compat directories, or have rebuilt everything using the new libarchive. I didn't! As I wrote before, this mess happened on ALL(!) freeBSD 10.0-CURRENT boxes in the very same way when I updated/reinstalled security/cyrus-sasl2. Moreover: I can reproduce this on all boxes. All my boxes use OpenLDAP as a backend with SASL2 enabled (not used so far). On this specific box, where this nasty problem also occured the same way by simply recompiling everything for port www/apache22, including the reinstallation of port security/cyrus-sasl2. Nearly every binary is suddenly coredumping (as on the home box). login, vi, install, devfs, syslogd, mtree, id, find ... a whole lot of binaries seem to be compromised by something I do not see (libsasl2.so perhaps?). truss the binaries to figure out exactly what's going wrong. I will try, but when this errative coredumps of binaries occur, nothing works properly that is using any kinf of dynamical loaded library! Only the binaries (static?) from /resucue/* do their work. A lot of this lost effort could be avoided (like others have posted on the list more than once), by having a centralized package distribution server, and by having VMs or jails and keeping snapshots with pre-upgrade state on the package building machine to avoid dead in the water scenarios like you're in right now. Yes, I'm working on this. it seems, that it becomes more relevant since I realized that FreeBSD suffers sometimes from misleaded ports or ports which suddenly are marked BROKEN and do not get compiled ... I tried to help myself via copying /rescue/vi to /usr/bin/vi to have at least a working vi. But in /rescue, I can not find install or mtree. I'm not familiar with the sophisticated ways of /rescue. Where are install(1) and mtree(1)? I ran into this issue too a little while ago. I basically gave up on recovering a VM and nuked and repaved it using a LiveCD with a chroot, some cp -p'ing, etc. But yes.. it would be nice if I could have recovered the system at least with a static toolchain: cc, binutils [equivalent], mtree, install, etc. This is how I recovered the nasty broken box. The other one was easy to recover by reinstalling security/cyrus-sasl2. I'm quite sure that there is something very foul with something in LDAP or SASL2, since I can reproduce that proplem. I saw that rtdl-elf has got some quirks these days, I will try to go behind the date/version of the source tree when it was committed and check whether this is the problem. ... Disabling this pkgng tag leads to reinstallation of missing packages, which are store in the pkgng sqlite format and not as ASCII anymore, but then I get /var/runld-elf.so.hints: No such file or directory Error: shared library iconv.3 does not exist. service ldconfig start ? Yes ... sorry ... in the heat of the fight I forgot ... but it doesn't make the problem go away. But most of the libs have never been touch! So what is the loader complaining about? ... I tried to find rescue images and a rescue DVD of a snap shot server, but there is no way to crawl through the informations on the web pages towards a snapshot. All folders end up in 2011 and highly outdated (www.freebsd.org, I didn't look at mirrors since I thought the main server carries the most recent stuff). This isn't funny. No lead, no hint, even in the download section. If someone has some hints how to recompile the sources with an emergency booted disk, I highly appreciate some desater advice. Maybe the release of FreeBSD-10-CURRENT sources I compiled do have accidentally a nasty bug, so it would be nice to update the sources and have a complete recompilation done. Thanks in advance, Simply
OpenLDAP/SASL2 problem in FreeBSD 10.0-CURRENT WAS: Re: HELP! core dumps: install, mtree, et cetera all of the sudden after portmaster security/cyrus-sasl2
As I reported in my previous help request, I discovered on ALL(!) of my FreeBSD 10.0-CURRENT box a very strange problem. Attached, you'll find /etc/src.conf - which might give hints what I'm doing wrong. Another issue might be pkg(ng), I changed to that recently (a week ago), but had no problems so far. Well, the issue: The setup: My setups on all boxes using OpenLDAP, the port net/opendldap24-client/server has security/cyrus-sasl2 enabled. I use nsswitch and nascd. My systems are all compiled using CLANG. The problem: I can not anymore install or reinstall (using portmaster, patched for pkgng) the ports security/cyrus-sasl2 net/openldap24-client When performing an update (no matter which one), The installation process dies when installing the packages (see error for openldap-cleint below, it is proxy for cyrus-sasl2 also). After a failed installation, close to all binaries I touch start to coredump in a mustang way. ls(1) works, but ls -la dumps core (resolving the ownership-issue?). The only way to save the box is to copy missing libldap_r-2.4.so.8 or libsasl2.so.2 to /usr/local/lib/ from another, compatible box or from a backup. The problem occured when I had to recompiled every requirements for port www/apache22, which failed after the last update on FreeBSD 10.0-CURRENT boxes AND FreeBSD 9.1-PRE boxes. After recompiling with portmaster -f apache22 on FreeBSD 9.1-PRE, things were all right again, but not on FreeBSD 10.0-CURRENT. It is impossible to me to update/reinstall either net/openldap24-client or security/cyrus-sasl2. When in single user mode with updated /usr/ports and distfiles for compilation or even with precompiled port, ready for being installed via make install, soon after starting make install something hidden runs wrong and the problems with rogue coredumping bins are there. My observation may be sloppy, sorry for that. I realise, that every static binary from /rescue work fine (but missing install and mtree, which are essentiall for installations, they coredump as well as other programs which seem to need user informations provided by LDAP) ERROR messages: === Creating a backup package for old version openldap-sasl-client-2.4.32_1 Creating package for openldap-sasl-client-2.4.32_1 The following packages will be deinstalled: openldap-sasl-client-2.4.32_1 The deinstallation will free 6 MB Deinstalling openldap-sasl-client-2.4.32_1...openldap-sasl-client-2.4.32_1 is required by: akonadi-1.7.2_3 apr-ipv6-devrandom-gdbm-db5-ldap24-pgsql91-sqlite3-1.4.5.1.3.12_1 cups-base-1.5.2_2 cups-samba-6.0_7 curl-7.24.0 cyrus-sasl-ldapdb-2.1.25 dirmngr-1.1.0_8 foomatic-db-20090530_2 foomatic-db-engine-4.0.7,2 gdal-grass-1.4.3_10 gpgme-1.3.2 grass-6.4.2_4,2 ldapvi-1.7_3 libcmis-0.1.0 luma-2.3_9 nss_ldap-1.265_7 openldap-sasl-server-2.4.32_1 pam_ldap-1.8.6_2 php5-5.4.5 py27-ldap2-2.4.10 raptor2-2.0.8 rasqal-0.9.29 soprano-2.7.6 gconf2-2.32.0_3 libgsf-1.14.21_1 librsvg2-2.34.1_1 ImageMagick-6.7.8.6 goffice-0.8.17_2 wv-1.2.9_1 abiword-2.8.4_2 alsa-plugins-1.0.25 wxgtk2-common-2.8.12_1 wxgtk2-unicode-2.8.12_1 codelite-4.0.5589 libwpd-0.9.4_1 libwpg-0.2.1_1 libvisio-0.0.18 libwps-0.2.7 libreoffice-3.5.5 de-libreoffice-3.5.5 gnome-vfs-2.24.4_1 webkit-gtk2-1.4.3_1 libcanberra-0.28_3 libgnome-2.32.0_1 libbonoboui-2.24.4_1 libgnome-keyring-2.32.0_2 libsoup-gnome-2.34.3_2 policykit-gnome-0.9.2_6 gnome-mount-0.8_10 gvfs-1.6.6_3 gnome-keyring-2.32.1_2 libgnomeui-2.24.4_1 devhelp-2.32.0_2,1 dia-gnome-0.97.1_3,1 subversion-1.7.5 docproj-1.17_6 docproj-jadetex-1.17_6 dvdauthor-0.7.0_3 en_GB-libreoffice-3.5.5 wxgtk2-2.8.12_1 gnuplot-4.6.0_2 fityk-0.9.4_2 gtksourceview2-2.10.5_1 py27-gtksourceview-2.10.1_1 gedit-2.30.4_2 gucharmap-2.32.1_1 gedit-plugins-2.32.0_2 gegl-0.1.8_4 gimp-app-2.6.12_1,1 gimp-gutenprint-5.2.8 glade3-gnome-3.7.3_1 libgsf-gnome-1.14.21_1 gnumeric-1.10.17_1 iourbanterror-4.1.1.s2244_1,1 kdelibs-4.8.4 kactivities-4.8.4 kde-wallpapers-4.8.4 libdmtx-0.7.4_2 prison-1.0_1 kdepimlibs-4.8.4 polkit-kde-0.99.0_3 kde-workspace-4.8.4 xine-0.99.7_1 kdenlive-0.9.2_1 libpurple-2.10.6 libreoffice-i18n-3.5.5 maxima-5.27.0_2 mdbtools-gnome-0.5_14 p5-subversion-1.7.5 pecl-imagick-3.1.0.r2 wxgtk2-contrib-common-2.8.12_1 wxgtk2-unicode-contrib-2.8.12_1 pgadmin3-1.14.2_1 pidgin-2.10.6 pidgin-otr-3.2.1 postgis-1.5.3_2 py27-gimp-app-2.6.12_1 wxgtk2-contrib-2.8.12_1 py27-wxPython-common-2.8.12.1_1 py27-wxPython-2.8.12.1_1 seahorse-2.32.0_7 swt-devel-3.7.1_1,1 virtualbox-ose-4.1.18 vuze-4.7.0.2 wxglade-0.6.5_1 yelp-2.30.2_3 thunderbird-enigmail-1.4.3 gnupg-2.0.19_2 samba36-3.6.7 samba36-libsmbclient-3.6.7 alpine-2.00_3 pulseaudio-0.9.23_2 redland-1.0.15_1 apache-2.2.22_6 postgresql-server-9.1.5 sudo-1.8.5.p3 mutt-1.5.21, deleting anyway done === Installing for openldap-sasl-client-2.4.32_1 === Generating temporary packing list Segmentation fault (core dumped) *** [install-mtree] Error code 139 Stop in /usr/ports/net/openldap24-sasl-client. *** [install] Error code 1 Stop in
Re: Time to bump default VM_SWZONE_SIZE_MAX?
On Tuesday, August 14, 2012 02:47:47 AM Dag-Erling Smørgrav wrote: Colin Percival cperc...@freebsd.org writes: If I'm understanding things correctly, the maxswzone value -- set by the kern.maxswzone loader tunable or to VM_SWZONE_SIZE_MAX by default -- should be approximately 9 MiB per GiB of swap space. Far less, in fact. As mentioned in loader(8), the default 32 MB limit is enough for slightly more than 7 GB of swap space - assuming 100% efficient use of swblocks. The man page recommends not using more than half the theoretical limit, or, with 16 pages per swblock, 1 maxswzone x s --- x --- 2 16 where s = 276 on 32-bit systems and 288 on 64-bit systems. The current default for VM_SWZONE_SIZE_MAX was set in August 2002 to 32 MiB; meaning that anyone who wants to use more than ~ 3.5 GB of swap space ought to set kern.maxswzone in /boot/loader.conf. Is it time to increase this default on amd64? (I understand that keeping the value low on i386 is important due to KVA limitations, but amd64 has far more address space available...) There is no reason to keep this limit at all. The algorithm used to size the zone is physpages / 2 * sizeof(struct swblock) or maxswzone, whichever is smaller where maxswzone == VM_SWZONE_SIZE_MAX unless kern.maxswzone was set in loader.conf. On amd64, the cutoff point is slightly below 1 GB of physical memory (233,016 4,096-byte pages), so the limit doesn't help machines that actually need to conserve memory, and it hurts machines that have plenty of it and therefore also plenty of swap (assuming the user followed the old twice the amount of RAM rule of thumb). Hmm, this is not true on i386 where the problem is not just the physical RAM required, but also address space. (The swap zone is all mapped into KVA even if it isn't used.) This is why Alan's e-mail specifically mentioned amd64, ia64, etc. but not i386 in his list. I think i386 still needs this limit, and I think your commit jumped the gun a bit. -- 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: panic: page fault
On Tuesday, August 14, 2012 05:29:09 AM Ivan Klymenko wrote: http://privatepaste.com/147286442b It is easier to reply if the messages are inline (for future reference). The panic and relevant bit of backtrace are below. Sadly, trying to cut and paste this destroyed the formatting, so I've tried to fix it by hand. :( Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x18 fault code = supervisor read data, page not present instruction pointer = 0x20:0x80933e07 stack pointer = 0x28:0xff823025b660 frame pointer = 0x28:0xff823025b6c0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 12 (irq256: bce0) trap number = 12 panic: page fault #6 0x80bb5e53 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:228 #7 0x80933e07 in m_copym (m=0x0, off0=1500, len=1480, wait=1) at /usr/src/sys/kern/uipc_mbuf.c:542 #8 0x809f8b76 in ip_fragment (ip=0xfe004b2f3980, m_frag=0xff823025b7c8, mtu=Variable mtu is not available. ) at /usr/src/sys/netinet/ip_output.c:822 #9 0x809f948a in ip_output (m=0xfe004b2f3900, opt=Variable opt is not available. ) at /usr/src/sys/netinet/ip_output.c:654 #10 0x809f59fa in ip_forward (m=0xfe004b2f3900, srcrt=Variable srcrt is not available. ) at /usr/src/sys/netinet/ip_input.c:1494 #11 0x809f6dc6 in ip_input (m=0xfe004b2f3900) at /usr/src/sys/netinet/ip_input.c:702 Can you run kgdb again and do 'frame 8' followed by 'p *m_frag', 'p m0', and 'p *m0'? Can you also grab my gdb scripts at www.freebsd.org/~jhb/gdb/ and run 'cd /path/to/scripts', 'source gdb6', 'mbuf m0' as well? -- 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
kernel page fult for a valid pointer?
Hi, I am wondering is there a reason for getting Fatal trap 12: page fault while in kernel mode supervisor read, page not present for an address used to be valid in kernel space? I dont really understand why I am getting this, I added a hardware watchpoint on the address, and when I got to the debuger I could read the memory content and dump for that address. But when I continue from the debugger I get the panic and now when I try to read the memory content I get *** error reading from address ce733000 ***. I am playing around with the kernel, but I dont really understand why this is happening or how I can track it down. Things worth noting, I am working on FreeBSD Current @ VirtualBox with VIMAGE enabled using jails. If there is any useful info I can collect it. br, -- Monthadar Al Jaberi ___ 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: CURRENT as gateway on not-so-fast hardware: where is a bottlneck?
Hello, Ian. You wrote 17 августа 2012 г., 18:56:33: IL That result actually matches my expectation... it fixed only a part of IL your problem. I was (partly) wrong :( Under ``really high'' load (4MiB/s up/down load in same time) userland freezes again. Unfortunately, it is difficult to repeat such load on request in y case, so I don't have KTR of scheduling in such case, but here is one thing I notice: when load is lower (like 2MiB/s both ways) ng_queue consume only 4-5% of CPU. And before freeze top shows ng_queue consumes about 60% of CPU. It is strange, as traffic goes up only at x2 rate... -- // Black Lion AKA Lev Serebryakov l...@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: OpenLDAP/SASL2 problem in FreeBSD 10.0-CURRENT WAS: Re: HELP! core dumps: install, mtree, et cetera all of the sudden after portmaster security/cyrus-sasl2
On 8/18/2012 4:07 AM, O. Hartmann wrote: My setups on all boxes using OpenLDAP, the port net/opendldap24-client/server has security/cyrus-sasl2 enabled. I use nsswitch and nascd. The problem: I can not anymore install or reinstall (using portmaster, patched for pkgng) the ports security/cyrus-sasl2 net/openldap24-client When performing an update (no matter which one), The installation process dies when installing the packages (see error for openldap-cleint below, it is proxy for cyrus-sasl2 also). After a failed installation, close to all binaries I touch start to coredump in a mustang way. ls(1) works, but ls -la dumps core (resolving the ownership-issue?). The only way to save the box is to copy missing libldap_r-2.4.so.8 or libsasl2.so.2 to /usr/local/lib/ from another, compatible box or from a backup. It is impossible to me to update/reinstall either net/openldap24-client or security/cyrus-sasl2. === Installing for openldap-sasl-client-2.4.32_1 === Generating temporary packing list Segmentation fault (core dumped) *** [install-mtree] Error code 139 What happens if you disable both LDAP and cache support from NSS before upgrading either of those two packages? Installing files certainly must invoke functions that need to translate owners/groups to uid/gid so perhaps something related to that suddenly fails during an attempt to replace the library. It sounds like if your LDAP support becomes corrupt, then it leaves a gaping hole in the NSS critical path that many parts of the system must be using. When you run into this situation and can resolve it easily by replacing the old ldap library, is the old one corrupt? Missing? Can you save a copy for evaluation? Does your system break in a similar manner simply by renaming the LDAP library, or does it behave worse only if there is a faulty LDAP library being used by nss_ldap? ___ 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
BUFSIZ = 1024, still ?
Shouldn't we at least increase it to pagesize ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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: BUFSIZ = 1024, still ?
On 8/18/2012 1:32 PM, Poul-Henning Kamp wrote: Shouldn't we at least increase it to pagesize ? What data suggests to you it would be better at pagesize? ___ 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: BUFSIZ = 1024, still ?
In message 5030033b.4060...@feral.com, Matthew Jacob writes: On 8/18/2012 1:32 PM, Poul-Henning Kamp wrote: Shouldn't we at least increase it to pagesize ? What data suggests to you it would be better at pagesize? The number of system calls to fwrite() a big file ? What evidence would there be that it would hurt ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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: BUFSIZ = 1024, still ?
On 8/18/2012 2:05 PM, Poul-Henning Kamp wrote: In message 5030033b.4060...@feral.com, Matthew Jacob writes: On 8/18/2012 1:32 PM, Poul-Henning Kamp wrote: Shouldn't we at least increase it to pagesize ? What data suggests to you it would be better at pagesize? The number of system calls to fwrite() a big file ? What evidence would there be that it would hurt ? I am normally not this conservative, but I see this as why make a change? If you're concerned about performance, you won't be using fwrite, you'll use O_DIRECT and do your own alignment. But I see your point. One could vaguely argue that a 4K BUFSIZ will put at risk more data on crashes needlessly. One could also vaguely say that the write syscall isn't expensive in and of itself, and that there might be a measurable difference for having to copy 4K (unaligned) than 1K (unaligned) to kernel space for disposition. Wasn't there just a recent discussion about running 1.x binaries? One reason we can do things like that is basic constants don't change very often. I believe the last time I saw BUFSIZ change was from BSD 2.9 to BSD 4.0, but I probably misremember that. If you're going to talk about making a change to defaults, the default MAXPHYS and DLFTPHYS have been undersized for years now. ___ 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: BUFSIZ = 1024, still ?
In message 50300540.9060...@feral.com, Matthew Jacob writes: [...] that there might be a measurable difference for having to copy 4K (unaligned) than 1K (unaligned) to kernel space for disposition. Actually, as far as I'm aware, the 4K would be page-aligned by default due to our malloc(3) implementation. Wasn't there just a recent discussion about running 1.x binaries? 1.x binaries wouldn't notice and wouldn't be able to tell if BUFSIZ is different in 10.x If you're going to talk about making a change to defaults, the default MAXPHYS and DLFTPHYS have been undersized for years now. Indeed, but as I understand it, those require device driver changes ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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: BUFSIZ = 1024, still ?
On 8/18/2012 2:36 PM, Poul-Henning Kamp wrote: In message 50300540.9060...@feral.com, Matthew Jacob writes: [...] that there might be a measurable difference for having to copy 4K (unaligned) than 1K (unaligned) to kernel space for disposition. Actually, as far as I'm aware, the 4K would be page-aligned by default due to our malloc(3) implementation. Wasn't there just a recent discussion about running 1.x binaries? 1.x binaries wouldn't notice and wouldn't be able to tell if BUFSIZ is different in 10.x I wasn't concerned about those specifically- I was just using this as an example of leaving stuff alone. If you're going to talk about making a change to defaults, the default MAXPHYS and DLFTPHYS have been undersized for years now. Indeed, but as I understand it, those require device driver changes ? Ah, well 10.X would be an ideal time to find out! ___ 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
