Re: prefer tsc timecounter when it's good
on 26/04/2011 20:49 Jung-uk Kim said the following: Can you please test attached patch? You can get it from here, too: http://people.freebsd.org/~jkim/tsc_smp_test.diff I am planning on testing the patch, but I am a little bit busy with other things at the moment. The idea looks good to me. The code is a little bit hard to follow :-) I would use three separate array instead of a single array with triple size (for clarity). The arrays would have to be placed inside a structure for passing to smp_rendezvous. Also, perhaps a single rendezvous per iteration would be sufficient, so that you get four values to compare per a pair of CPUs, instead of current six. Again to make the code simpler / more readable. That would allow to expand TSC_READ macro as well (two copies of the function would take less lines than the macro). BTW, not sure if you actually need 'volatile' inside tsc_read_X. Currently this patch samples 3,000 times to determine if any CPU has out-of-order TSC but it may be too much, especially for large SMP machines. If it takes too long, I'll lower the number. Please report if that's the case. Please note this patch also changes HPET, ACPI-fast and TSC qualities. However, TSC on SMP does not change the default quality, i.e., HPET or ACPI timer will be chosen by default, because we cannot be sure if they'll drift later. If the user is sure that they don't drift AND it is absolutely constant, kern.timecounter.smp_tsc tunable can be used to set better quality. - You changing the relative priorities of HPET and ACPI-fast. I support this change (some others may not), but please make it as a separate commit. - Not sure if the quality test code is of much use if a user has to set some tunable to actually use it over HPET or ACPI-fast. I thought that the whole point was in automatically choosing the best timecounter. I would go the opposite way - if automatic selection of TSC causes any trouble then provide a way to disable it. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: A replacement for GEOM_LABEL's gpt/gptid
On 25.04.2011 14:38, Andrey V. Elsukov wrote: I wrote a small extension for the GEOM_PART class. It adds an ability to GEOM_PART class to create partition labels for schemes which are support them. Currently we have GEOM_LABEL class which does similar functions, but it has problems in conjunction with GEOM_PART (e.g. kern/154226). Current implementation of GEOM_LABEL's gpt/gptid module does direct access to GEOM_PART object structures, that seems not so good for me. So, my patch contains: * new GEOM class PART::LABEL. It attaches to partition provider and create new providers for each label. * new kobj method - G_PART_LABELS. It called when new partition is creating. A partition scheme can implement this method if it supports partition labels. Method should just call g_part_create_label() function to create new label for given partition. * g_part_spoil_labels() function. It called from GEOM_PART to destroy labels providers or mark them stale. At this time it called only from gpart modify method. What differs from GEOM_LABEL: * PART::LABEL class has not .spoiled method and all providers are persistent. * if label is changing while provider is in use, it will not be destroyed until access does not released, but new label will become available. * also it has support for APM and PC98 schemes. The patch is here: http://people.freebsd.org/~ae/gpart_labels.diff I updated the patch, it is in the same location. I turned off glabel's gpt/gpid support and added loader tunables: kern.geom.part_label.apm.enable kern.geom.part_label.gpt.enable kern.geom.part_label.gptid.enable kern.geom.part_label.pc98.enable Also for compatibility glabel's tunables still here: kern.geom.label.gpt.enable kern.geom.label.gptid.enable So, if you have them in your loader.conf and want to have gpt/gptid labels, you should remove them from loader.conf. Also now they are only loader tunables and they can not be changed in runtime. If there will no objections i am planning to commit patch in this weekend. -- WBR, Andrey V. Elsukov signature.asc Description: OpenPGP digital signature
FreeBSD Status Report January-March, 2011
FreeBSD Quarterly Status Report January-March, 2011 Introduction This report covers FreeBSD-related projects between January and March 2011. It is the first of the four reports planned for 2011. During this quarter, the work was focused on releasing the new minor versions of FreeBSD, 7.4 and 8.2, which were released in February 2011. Currently, the project is starting to work on the next major version, 9.0. Thanks to all the reporters for the excellent work! This report contains 34 entries and we hope you enjoy reading it. Please note that the deadline for submissions covering the period between April and June 2011 is July 15th, 2011. __ Projects * Bringing up OMAP3 * GEOM-based ataraid(4) Replacement -- geom_raid. * HAST (Highly Available Storage) * New FreeBSD Installer * OpenAFS Port * pfSense * RCTL, aka Resource Containers * ZFSv28 available in FreeBSD 9-CURRENT FreeBSD Team Reports * FreeBSD Bugbusting Team * FreeBSD NYI Admins Status Report * The FreeBSD Foundation Status Report Network Infrastructure * DIstributed Firewall and Flow-shaper Using Statistical Evidence (DIFFUSE) * Five New TCP Congestion Control Algorithms for FreeBSD Kernel * Journaled Soft Updates * Linux Compatibility Layer - DVB and V4L2 Support Documentation * New FreeBSD Handbook Section Covering HAST * The FreeBSD German Documentation Project Status Report * The FreeBSD Japanese Documentation Project * Webcam and DVB Compatibility List Architectures * FreeBSD/arm on Marvell Raid-on-Chip * FreeBSD/EC2 * FreeBSD/powerpc on Freescale QorIQ * MIPS/Octeon Support and bootinfo Ports * FreeBSD as Home Theater PC * FreeBSD Chromium * FreeBSD Haskell Ports * KDE-FreeBSD * Linux Emulation Ports * Portmaster * Ports Collection * www/apache22 Default Miscellaneous * BSDCan Google Summer of Code * Extfs Status Report * Google Summer of Code 2011 __ Bringing up OMAP3 Contact: Warner Losh i...@bsdimp.com Contact: Mohammed Farrag mfar...@freebsd.org OMAP3 Emulation: * Step #1: qemu-omap3 isn't ported to FreeBSD yet. So, * Step #2: Use qemu-omap3 on Gentoo Host .. * Step #3: Is the end reached ?! No, bcz qemu-omap3 is not full. So, go to step #4. * Step #4: Use Meego Download Ubuntu 10.10 Install it, and * Step #5: Compile FreeBSD kernel, Create root file system, mkimage, Emulate using Meego. Open tasks: 1. Device Drivers for OMAP3 Processors. __ BSDCan URL: http://www.bsdcan.org/2011/ Contact: Dan Langille d...@freebsd.org Our list of talks has been settled, and the schedule is pretty much finalized. There is still time to get into the Works In Progress session. Best to book your on-campus accommodation now. Or stay at one of the nearby hotels. Open tasks: 1. Show up. Enjoy. Profit. __ DIstributed Firewall and Flow-shaper Using Statistical Evidence (DIFFUSE) URL: http://caia.swin.edu.au/urp/diffuse/ URL: http://caia.swin.edu.au/urp/diffuse/downloads.html Contact: Sebastian Zander szan...@swin.edu.au Contact: Grenville Armitage garmit...@swin.edu.au DIFFUSE is a system enabling FreeBSD's IPFW firewall subsystem to classify IP traffic based on statistical traffic properties. With DIFFUSE, IPFW computes statistics (such as packet lengths or inter-packet time intervals) for observed flows, and uses ML (machine learning) to classify flows into classes. In addition to traditional packet inspection rules, IPFW rules may now also be expressed in terms of traffic statistics or classes identified by ML classification. This can be helpful when direct packet inspection is problematic (perhaps for administrative reasons, or because port numbers do not reliably identify applications). DIFFUSE also enables one instance of IPFW to send flow information and classes to other IPFW instances, which then can act on such traffic (e.g. prioritise, accept, deny, etc.) according to its class. This allows for distributed architectures, where classification at one location in your network is used to control fire-walling or rate-shaping actions at other locations. DIFFUSE is a set of patches for FreeBSD-CURRENT. It can be downloaded from the project's web site. The web site also contains a more comprehensive introduction, including application examples, links to related work and documentation. In February 2011 we released DIFFUSE v0.2.2. This release contains a number of bug fixes and new features. Most
Re: problems with em(4) since update to driver 7.2.2
2011/3/31 Jack Vogel jfvo...@gmail.com: This problem happens for only one reason, you have insufficient mbufs to fill your rx ring. Its odd that it would differ when its static versus a loadable module though! With the 7.2.2 driver you also will use different mbuf pools depending on the MTU you are using. If you use jumbo frames it will use 4K clusters, if you go to 9K jumbos it will use 9K mbuf clusters. The number of these allocated by default is small (like 6400 small :). I would use 'netstat -m' to see what the pools look like. Now that I think about it, the reason it might fail as loaded while not as built in is you get allocation of the mbufs first when static, and something else is taking them before you can load when loadable?? Sorry to be quite late on this, Here is what gives me netstat -m with my new 9-CURRENT kernel but with old (working, after some time of computer use) if_em.ko : 1027/3458/4485 mbufs in use (current/cache/total) 1024/2066/3090/25600 mbuf clusters in use (current/cache/total/max) 1024/1792 mbuf+clusters out of packet secondary zone in use (current/cache) 0/367/367/12800 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) 2304K/6464K/8769K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines And here is the output with the new (non-working) if_em.ko : 1029/3456/4485 mbufs in use (current/cache/total) 1023/2067/3090/25600 mbuf clusters in use (current/cache/total/max) 1023/1793 mbuf+clusters out of packet secondary zone in use (current/cache) 0/367/367/12800 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) 2303K/6466K/8769K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines I've got the em0: Could not setup receive structures messages with the new if_em.ko even in single user mode. No network connectivity. I tried removing all other network-related modules (vboxnet, ipfw...) and still have this problem (again, even when booting in single-user mode). My network card is em0@pci0:0:25:0:class=0x02 card=0x304b103c chip=0x10ef8086 rev=0x05 hdr=0x00. I'm using a stripped-down GENERIC amd64 kernel (no network, no scsi, no raid...), a nearly empty sysctl.conf and loader.conf (except module loading). I saw at the time of the commit that an MFC to 8-STABLE was planned, but I don't think it should happen so soon. Given that my network adapter was previously working well before the em driver update, can't this be considerd a serious regression ? Thanks, Olivier -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: oliv...@gid0.org - against HTML email vCards X www: http://www.gid0.org - against proprietary attachments / \ Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas. ___ 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: A replacement for GEOM_LABEL's gpt/gptid
On 04/27/11 02:37, Andrey V. Elsukov wrote: On 25.04.2011 14:38, Andrey V. Elsukov wrote: I wrote a small extension for the GEOM_PART class. It adds an ability to GEOM_PART class to create partition labels for schemes which are support them. Currently we have GEOM_LABEL class which does similar functions, but it has problems in conjunction with GEOM_PART (e.g. kern/154226). Current implementation of GEOM_LABEL's gpt/gptid module does direct access to GEOM_PART object structures, that seems not so good for me. So, my patch contains: * new GEOM class PART::LABEL. It attaches to partition provider and create new providers for each label. * new kobj method - G_PART_LABELS. It called when new partition is creating. A partition scheme can implement this method if it supports partition labels. Method should just call g_part_create_label() function to create new label for given partition. * g_part_spoil_labels() function. It called from GEOM_PART to destroy labels providers or mark them stale. At this time it called only from gpart modify method. What differs from GEOM_LABEL: * PART::LABEL class has not .spoiled method and all providers are persistent. * if label is changing while provider is in use, it will not be destroyed until access does not released, but new label will become available. * also it has support for APM and PC98 schemes. The patch is here: http://people.freebsd.org/~ae/gpart_labels.diff I updated the patch, it is in the same location. I turned off glabel's gpt/gpid support and added loader tunables: kern.geom.part_label.apm.enable kern.geom.part_label.gpt.enable kern.geom.part_label.gptid.enable kern.geom.part_label.pc98.enable Also for compatibility glabel's tunables still here: kern.geom.label.gpt.enable kern.geom.label.gptid.enable So, if you have them in your loader.conf and want to have gpt/gptid labels, you should remove them from loader.conf. Also now they are only loader tunables and they can not be changed in runtime. If there will no objections i am planning to commit patch in this weekend. This is fantastic. Thank you! -Nathan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: problems with em(4) since update to driver 7.2.2
If you get cannot setup receive structures you cannot go on and try to use the thing :) It means you have inadequate mbuf clusters to setup your receive side, you simply have to increase it and reload the driver. Jack On Wed, Apr 27, 2011 at 5:39 AM, Olivier Smedts oliv...@gid0.org wrote: 2011/3/31 Jack Vogel jfvo...@gmail.com: This problem happens for only one reason, you have insufficient mbufs to fill your rx ring. Its odd that it would differ when its static versus a loadable module though! With the 7.2.2 driver you also will use different mbuf pools depending on the MTU you are using. If you use jumbo frames it will use 4K clusters, if you go to 9K jumbos it will use 9K mbuf clusters. The number of these allocated by default is small (like 6400 small :). I would use 'netstat -m' to see what the pools look like. Now that I think about it, the reason it might fail as loaded while not as built in is you get allocation of the mbufs first when static, and something else is taking them before you can load when loadable?? Sorry to be quite late on this, Here is what gives me netstat -m with my new 9-CURRENT kernel but with old (working, after some time of computer use) if_em.ko : 1027/3458/4485 mbufs in use (current/cache/total) 1024/2066/3090/25600 mbuf clusters in use (current/cache/total/max) 1024/1792 mbuf+clusters out of packet secondary zone in use (current/cache) 0/367/367/12800 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) 2304K/6464K/8769K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines And here is the output with the new (non-working) if_em.ko : 1029/3456/4485 mbufs in use (current/cache/total) 1023/2067/3090/25600 mbuf clusters in use (current/cache/total/max) 1023/1793 mbuf+clusters out of packet secondary zone in use (current/cache) 0/367/367/12800 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) 2303K/6466K/8769K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines I've got the em0: Could not setup receive structures messages with the new if_em.ko even in single user mode. No network connectivity. I tried removing all other network-related modules (vboxnet, ipfw...) and still have this problem (again, even when booting in single-user mode). My network card is em0@pci0:0:25:0:class=0x02 card=0x304b103c chip=0x10ef8086 rev=0x05 hdr=0x00. I'm using a stripped-down GENERIC amd64 kernel (no network, no scsi, no raid...), a nearly empty sysctl.conf and loader.conf (except module loading). I saw at the time of the commit that an MFC to 8-STABLE was planned, but I don't think it should happen so soon. Given that my network adapter was previously working well before the em driver update, can't this be considerd a serious regression ? Thanks, Olivier -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: oliv...@gid0.org- against HTML email vCards X www: http://www.gid0.org- against proprietary attachments / \ Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas. ___ 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
Heads up: default nfs client switched to new one
The commit r221124 switches the default NFS client to the new one in head. The fstype newnfs is now nfs and the regular/old NFS client is now fstype oldnfs. As such, mount -t nfs ... will use the new client. Although most kernels will still work with the old mount(8) and mount_nfs(8) binaries (the exception is one built with options NFSCL but not options NFSCLIENT), you should build fresh mount(8) and mount_nfs(8) binaries. To use the old NFS client... You'll need new binaries for mount(8) and mount_nfs(8), plus a link in /sbin to mount_nfs called mount_oldnfs. Then you can use the old NFS client via: mount -t oldnfs ... Systems using a diskless root NFS fs will need to have the new client linked into their kernels via options NFSCL. Both options NFSCL and options NFSCLIENT can be specified for the kernel. If you do that, you can switch back to the old NFS client by changing the fstype field of etc/fstab for the root fs on the NFS server to oldnfs plus adding a line like: vfs.root.mountfrom=oldnfs: to boot/loader.conf in the root fs on the server. Hopefully, you won't need to do anything to keep things working and this won't cause you grief, rick ___ 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: problems with em(4) since update to driver 7.2.2
2011/4/27 Jack Vogel jfvo...@gmail.com: If you get cannot setup receive structures you cannot go on and try to use the thing :) It means you have inadequate mbuf clusters to setup your receive side, you simply have to increase it and reload the driver. Thanks for your answer. I'll try and let you know if this works, but why don't have I enough mbuf clusters ? Isn't this driver supposed to just work out of the box on a nearly GENERIC (but with network devices as modules) kernel ? -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: oliv...@gid0.org - against HTML email vCards X www: http://www.gid0.org - against proprietary attachments / \ Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas. ___ 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: problems with em(4) since update to driver 7.2.2
On 4/27/2011 2:35 PM, Olivier Smedts wrote: 2011/4/27 Jack Vogel jfvo...@gmail.com: If you get cannot setup receive structures you cannot go on and try to use the thing :) It means you have inadequate mbuf clusters to setup your receive side, you simply have to increase it and reload the driver. Thanks for your answer. I'll try and let you know if this works, but why don't have I enough mbuf clusters ? Isn't this driver supposed to just work out of the box on a nearly GENERIC (but with network devices as modules) kernel ? Are you testing with what is in HEAD ? ie. 7.2.3 or something else ? Your subject line implies something else. ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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: problems with em(4) since update to driver 7.2.2
2011/4/27 Mike Tancsa m...@sentex.net: On 4/27/2011 2:35 PM, Olivier Smedts wrote: 2011/4/27 Jack Vogel jfvo...@gmail.com: If you get cannot setup receive structures you cannot go on and try to use the thing :) It means you have inadequate mbuf clusters to setup your receive side, you simply have to increase it and reload the driver. Thanks for your answer. I'll try and let you know if this works, but why don't have I enough mbuf clusters ? Isn't this driver supposed to just work out of the box on a nearly GENERIC (but with network devices as modules) kernel ? Are you testing with what is in HEAD ? ie. 7.2.3 or something else ? Your subject line implies something else. I'm using what's in HEAD since r219753, the commit which updated the em driver from version 7.1.9 to 7.2.2 and broke it at least for me. From the commit log : This improves the RX mbuf handling to avoid system hang due to depletion. Well... not improved for everyone ;) Sorry if the subject wasn't clear. -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: oliv...@gid0.org - against HTML email vCards X www: http://www.gid0.org - against proprietary attachments / \ Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas. ___ 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: problems with em(4) since update to driver 7.2.2
On 4/27/2011 2:45 PM, Olivier Smedts wrote: Are you testing with what is in HEAD ? ie. 7.2.3 or something else ? Your subject line implies something else. I'm using what's in HEAD since r219753, the commit which updated the em driver from version 7.1.9 to 7.2.2 and broke it at least for me. Oh, ok. Thats from back in March. There is a newer one 7.2.3 in April. I would test with that perhaps. I am using a back ported version on RELENG8 and it works quite well for me. http://lists.freebsd.org/pipermail/svn-src-head/2011-April/026202.html Hopefully MFC'd soon ? ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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: prefer tsc timecounter when it's good
On Wednesday 27 April 2011 03:07 am, Andriy Gapon wrote: on 26/04/2011 20:49 Jung-uk Kim said the following: Can you please test attached patch? You can get it from here, too: http://people.freebsd.org/~jkim/tsc_smp_test.diff I am planning on testing the patch, but I am a little bit busy with other things at the moment. No problem. The idea looks good to me. The code is a little bit hard to follow :-) Sorry. The patch was updated to make it little easier to read: http://people.freebsd.org/~jkim/tsc_smp_test2.diff I would use three separate array instead of a single array with triple size (for clarity). The arrays would have to be placed inside a structure for passing to smp_rendezvous. Array of pointers... I tried that earlier but it made the code little bit more complex overall, actually. :-/ Also, perhaps a single rendezvous per iteration would be sufficient, so that you get four values to compare per a pair of CPUs, instead of current six. Again to make the code simpler / more readable. That would allow to expand TSC_READ macro as well (two copies of the function would take less lines than the macro). smp_rendezvous() is very expensive, so I wanted to get more samples per call. BTW, not sure if you actually need 'volatile' inside tsc_read_X. No, I don't, removed. FYI, it was part of my early experiments to find the cheapest way to work around cache issues, which never worked. Eventually, I ended up with calling smp_cache_flush(). :-( Currently this patch samples 3,000 times to determine if any CPU has out-of-order TSC but it may be too much, especially for large SMP machines. If it takes too long, I'll lower the number. Please report if that's the case. Please note this patch also changes HPET, ACPI-fast and TSC qualities. However, TSC on SMP does not change the default quality, i.e., HPET or ACPI timer will be chosen by default, because we cannot be sure if they'll drift later. If the user is sure that they don't drift AND it is absolutely constant, kern.timecounter.smp_tsc tunable can be used to set better quality. - You changing the relative priorities of HPET and ACPI-fast. I support this change (some others may not), but please make it as a separate commit. Yes, that is my intention but it's continuation of your original patch. :-) - Not sure if the quality test code is of much use if a user has to set some tunable to actually use it over HPET or ACPI-fast. I thought that the whole point was in automatically choosing the best timecounter. It can be extended to make better selection depending on vendor, model, topology, etc. if necessary. I would go the opposite way - if automatic selection of TSC causes any trouble then provide a way to disable it. POLA... Jung-uk Kim ___ 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: problems with em(4) since update to driver 7.2.2
Yes Mike, already have had a couple others bug me to get the MFC, I'm hoping to get it in this week :) Jack On Wed, Apr 27, 2011 at 12:04 PM, Mike Tancsa m...@sentex.net wrote: On 4/27/2011 2:45 PM, Olivier Smedts wrote: Are you testing with what is in HEAD ? ie. 7.2.3 or something else ? Your subject line implies something else. I'm using what's in HEAD since r219753, the commit which updated the em driver from version 7.1.9 to 7.2.2 and broke it at least for me. Oh, ok. Thats from back in March. There is a newer one 7.2.3 in April. I would test with that perhaps. I am using a back ported version on RELENG8 and it works quite well for me. http://lists.freebsd.org/pipermail/svn-src-head/2011-April/026202.html Hopefully MFC'd soon ? ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.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: Heads up: default nfs client switched to new one
On Wed, Apr 27, 2011 at 01:59:49PM -0400, Rick Macklem wrote: The commit r221124 switches the default NFS client to the new one in head. The fstype newnfs is now nfs and the regular/old NFS client is now fstype oldnfs. As such, mount -t nfs ... will use the new client. Hi, Is there any impact on /usr/sbin/amd? -- Craig Rodrigues rodr...@crodrigues.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: Heads up: default nfs client switched to new one
On Wed, Apr 27, 2011 at 01:59:49PM -0400, Rick Macklem wrote: The commit r221124 switches the default NFS client to the new one in head. The fstype newnfs is now nfs and the regular/old NFS client is now fstype oldnfs. As such, mount -t nfs ... will use the new client. Hi, Is there any impact on /usr/sbin/amd? I'll admit I haven't tested it (I've never used the FreeBSD amd). I will do so once I figure out how to set it up, but I'm hoping others will report any problems. If you can test it, that would be appreciated. (I can't think of why it wouldn't work, but...) rick ___ 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: responsiveness during IO tasks
On 04/26/2011 03:37, Alexander Best wrote: On Mon Apr 25 11, Steve Wills wrote: Hi, I've noticed lately that when doing heavy IO, my 9-CURRENT system (Fri Apr 15 23:33:46 EDT 2011) is quite unresponsive. I have two ZFS mirrors setup and run KDE4. The system has 12GB of RAM. When I, for example, copy an ISO image from one mirror to the other, the whole desktop becomes really slow during the copy. It takes a good 15 seconds to open a new tab in Konsole, switching windows takes a while, etc. Once the copy is finished, things are fine. It wasn't like this back before I upgraded from 8.2-RC1 to 9-CURRENT. Has anyone else noticed something similar, or is it just me? Is there any other info I can provide or something I should look for? i've noticed this too. for me the situation is sometimes even worse. during heavy i/o the mouse cursor won't even respond. i think this is a scheduler isse. maybe running a non-preemptive kernel or switching to the old 4bsd scheduler fixes it? Try backing up your src tree to r212540, clean /usr/obj, buildworld/kernel and see if that helps. I just tracked down a big part of my current problem (pun intended) to r212541, the one-shot timer commit. I'm working on a larger post to describe my problems, but short version is, up through r212540 I can load the system down as heavily as I want, and while there may be some unresponsiveness it's at least stable. If I update to one-shot timers the system wedges as soon as I put load on it. No panic, not even a reboot, it just wedges solid requiring it to be powered off. You should also test SCHED_4BSD to see if that improves your situation. There have been a lot of reports about problems with SCHED_ULE with heavy disk i/o. Moving to 4bsd helps me in terms of interactivity, but I needed to find the crashing problem first. hth, Doug (sorry mav) -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.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: Heads up: default nfs client switched to new one
On Wed, Apr 27, 2011 at 07:39:17PM -0400, Rick Macklem wrote: Hi, Is there any impact on /usr/sbin/amd? I'll admit I haven't tested it (I've never used the FreeBSD amd). I will do so once I figure out how to set it up, but I'm hoping others will report any problems. If you can test it, that would be appreciated. (I can't think of why it wouldn't work, but...) Hi, I'll try and test amd and give feedback. -- Craig Rodrigues rodr...@crodrigues.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: Heads Up: default NFS server changing to the new one
On Tue, Apr 26, 2011 at 09:26:05AM -0400, John Baldwin wrote: Actually, I think we should switch GENERIC in HEAD to the new client and kernel very soon. The goal is to get current users testing the new client and server so they can uncover any bugs. If problems crop up during the testing that can't be resolved, we can always revert to the older client/server for the release. Hi, I agree. I think it is fantastic that Rick is doing all this work in our NFS code. Unfortunately, for this kind of stuff, in order to uncover the interop issues and edge cases, it is better to make this the default sooner, rather than later. The people with the production setups where you uncover these kinds of issues don't run the tip of CURRENT usually One thing to consider: if we could provide a bootable virtual machine with the new NFS code to some of the storage vendors like EMC/Isilon, Netapp, etc. it might be nice to get some feedback. People are always busy, but if we make the effort to make things easier to try out and test, that is always a good thing. -- Craig Rodrigues rodr...@crodrigues.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: responsiveness during IO tasks
Doug Barton wrote: On 04/26/2011 03:37, Alexander Best wrote: On Mon Apr 25 11, Steve Wills wrote: I've noticed lately that when doing heavy IO, my 9-CURRENT system (Fri Apr 15 23:33:46 EDT 2011) is quite unresponsive. I have two ZFS mirrors setup and run KDE4. The system has 12GB of RAM. When I, for example, copy an ISO image from one mirror to the other, the whole desktop becomes really slow during the copy. It takes a good 15 seconds to open a new tab in Konsole, switching windows takes a while, etc. Once the copy is finished, things are fine. It wasn't like this back before I upgraded from 8.2-RC1 to 9-CURRENT. Has anyone else noticed something similar, or is it just me? Is there any other info I can provide or something I should look for? i've noticed this too. for me the situation is sometimes even worse. during heavy i/o the mouse cursor won't even respond. i think this is a scheduler isse. maybe running a non-preemptive kernel or switching to the old 4bsd scheduler fixes it? Try backing up your src tree to r212540, clean /usr/obj, buildworld/kernel and see if that helps. I just tracked down a big part of my current problem (pun intended) to r212541, the one-shot timer commit. I'm working on a larger post to describe my problems, but short version is, up through r212540 I can load the system down as heavily as I want, and while there may be some unresponsiveness it's at least stable. If I update to one-shot timers the system wedges as soon as I put load on it. No panic, not even a reboot, it just wedges solid requiring it to be powered off. You should also test SCHED_4BSD to see if that improves your situation. There have been a lot of reports about problems with SCHED_ULE with heavy disk i/o. Moving to 4bsd helps me in terms of interactivity, but I needed to find the crashing problem first. Doug (sorry mav) No problem, just let's hunt things down. I'll wait for that larger post. In meantime, if it is related to eventtimers, it would be good to collect more detailed information. You could try to make timer run during idle (kern.eventtimer.idletick). You could try to switch timer from one-shot to periodic mode (kern.eventtimer.periodic). You could also try to switch to another timer (kern.eventtimer.timer). -- 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
