Re: Detach USB Device Driver and Attach it to ugen driver at runtime
On Tuesday 06 September 2011 03:53:55 Daniel O'Connor wrote: On 05/09/2011, at 23:10, Daniel Grech wrote: Hi, I'm using libusb to gain access to raw USB Data from userspace. My problem is that this library only works with devices which are treated as generic devices (handled by the ugen driver). I need a mechanism that will allow me to detach any device specific drivers that are attached to a device and attach the ugen driver instead. I want to do this without re-compiling the FreeBSD Kernel. Thanks in advance for your help. You can access the device via ugen even if a kernel driver has attached to it. I suspect you wouldn't be able to if the kernel driver that did attach is in use, but I am not sure. You can attach even if a kernel driver is attached, though it is best to only have one driver attached at the same time. --HPS ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Recommended amount of swap
05.09.2011 22:48, Dan Nelson написав(ла): In the last episode (Sep 05), Sean Hamilton said: What is the state of the art for the recommended amount of swap in FreeBSD? Both normal systems with 512 MB - 8 GB of RAM, and large database systems with around 128 - 256 GB. I suggest 2x RAM for systems less than 4gb or so. Anything more than 4GB of swap is probably never going to be used, and if it is used, you're just going to thrash your swap device. If you have 128GB of RAM and need to swap to disk, you desperately need more RAM, not swap :) My +1 to wishlist, I want OpenOffice to not trash memory when reading large xlsx files. Mem: 1937M Active, 243M Inact, 672M Wired, 98M Cache, 9412K Free Swap: 36G Total, 21G Used, 15G Free, 59% Inuse, 252K In PID USERNAMETHR PRI NICE SIZERES STATE C TIME WCPU COMMAND 1912 arcade5 451 23311M 1721M ucond 0 66:07 55.37% /usr/local/openoffice.org-3.3.0/openoffice.org3/program/so Different things happens. When I hardly need some swap I think about: 0. More RAM. 1. Spare flash or SSD. 2. Another disk. 3. Touching disk sizes. Also please note that system that uses at least 1G of swap actively (I don't mean tmp/mdfs or long running non active processes) is dripping slime and therefor is useless and should be upgraded. -- Sphinx of black quartz judge my vow. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
excessive use of gettimeofday(2) and other syscalls
hi there, in a recent discussion on current@ [1], it was discovered that chromium makes excessive use of gettimeofday(2). while searching google, i found other software that is/was having the same issue [2]. although this is a programming error, it would still be nice, if freebsd could issue a warning in cases like these. would it be possible to instruct freebsd to issue a warning, when a process issues a certain amount of syscalls per second (maybe tuneable via sysctl)? while calling gettimeofday(2) excessively isn't causing any harm, it triggers a lot of context switches and reduces performance. having such warnings in place could help a user identify such a process without having to use debugging tools, such as ktrace or dtrace. cheers. alex [1] http://www.mail-archive.com/freebsd-current@freebsd.org/msg131040.html [1] https://forum.transmissionbt.com/viewtopic.php?f=2t=11687 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: excessive use of gettimeofday(2) and other syscalls
Under 7.3 (haven't checked 8 or 9) this issue crops up because the time system call calls gettimeofday under the hood (see lib/libc/gen/time.c). As a result, the kernel tries to get an accurate subsecond resolution time that simply gets chopped to the nearest second. Lots of libraries assume that time is fast because it is fast under Linux. Every instance where I have seen this as a performance issue, the call has been to time not a direct call to gettimeofday. The latest openssl (not the one from FreeBSD, but the one from openssl.org has this issue for example. Manish On Tue, Sep 6, 2011 at 4:01 PM, Alexander Best arun...@freebsd.org wrote: hi there, in a recent discussion on current@ [1], it was discovered that chromium makes excessive use of gettimeofday(2). while searching google, i found other software that is/was having the same issue [2]. although this is a programming error, it would still be nice, if freebsd could issue a warning in cases like these. would it be possible to instruct freebsd to issue a warning, when a process issues a certain amount of syscalls per second (maybe tuneable via sysctl)? while calling gettimeofday(2) excessively isn't causing any harm, it triggers a lot of context switches and reduces performance. having such warnings in place could help a user identify such a process without having to use debugging tools, such as ktrace or dtrace. cheers. alex [1] http://www.mail-archive.com/freebsd-current@freebsd.org/msg131040.html [1] https://forum.transmissionbt.com/viewtopic.php?f=2t=11687 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org -- Manish Vachharajani Founder LineRate Systems mani...@lineratesystems.com (609)635-9531 M ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: excessive use of gettimeofday(2) and other syscalls
On Tue, Sep 6, 2011 at 6:44 PM, Manish Vachharajani mani...@lineratesystems.com wrote: Lots of libraries assume that time is fast because it is fast under Linux. Silly question, but why can't we make it fast too? -- Eitan Adler ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: excessive use of gettimeofday(2) and other syscalls
I believe that Linux uses a less precise clock that scales better across cores and is much faster than the precise clock FreeBSD uses even on one core. I don't know POSIX and other standards well enough to know if this is an acceptable solution on FreeBSD. However, there are less precise clocks on FreeBSD that are considerably faster (i.e., the _FAST variants). Someone with more expertise in these matters needs to comment on whether a change to using a _FAST clock is appropriate in libc. If it is acceptable, I think that it is easier to just make time use the FAST clock instead of getting programmers to change their programs. On Tue, Sep 6, 2011 at 6:41 PM, Eitan Adler li...@eitanadler.com wrote: On Tue, Sep 6, 2011 at 6:44 PM, Manish Vachharajani mani...@lineratesystems.com wrote: Lots of libraries assume that time is fast because it is fast under Linux. Silly question, but why can't we make it fast too? -- Eitan Adler Manish ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
VMWare/Virtualbox virtio network drivers?
Hi all, Am wondering if anyone has done drivers the these sorts of network interfaces that are offered by VMWare Virtual box. I know that on some Linux VMs I run, performance went from 20MB/s to 30MB/s to an NFS server which I swicthed to the virtio network interfaces. Stephen ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: excessive use of gettimeofday(2) and other syscalls
There are some recent discussions on the freebsd-current list. The infrastructure is there to provide a common shared page for processes to mmap into the address space... but according to Kip's comment, libc support is not there yet: http://lists.freebsd.org/pipermail/freebsd-current/2011-June/025191.html Also, the kernel needs to update the variable in that shared page on each clock interrupt (depending on the resolution I believe), and I think that needs to be added too. IMO, the time returned by gettimeofday does not need to be high precision. There are higher resolution time APIs on Linux and I believe the application programmers know when to use the slower but more accurate clock API. (At least in Grid Engine we only need a quick way of getting the current time, and we don't care if it is precise to the nanosecond range.) See Linux security issue solution: http://lwn.net/Articles/446528/ See also the Google SoC idea: http://wiki.freebsd.org/IdeasPage#Timecounter_Performance_Improvements_.28GSoC.29 Rayson = Grid Engine / Open Grid Scheduler http://gridscheduler.sourceforge.net On Tue, Sep 6, 2011 at 8:49 PM, Manish Vachharajani mani...@lineratesystems.com wrote: I believe that Linux uses a less precise clock that scales better across cores and is much faster than the precise clock FreeBSD uses even on one core. I don't know POSIX and other standards well enough to know if this is an acceptable solution on FreeBSD. However, there are less precise clocks on FreeBSD that are considerably faster (i.e., the _FAST variants). Someone with more expertise in these matters needs to comment on whether a change to using a _FAST clock is appropriate in libc. If it is acceptable, I think that it is easier to just make time use the FAST clock instead of getting programmers to change their programs. On Tue, Sep 6, 2011 at 6:41 PM, Eitan Adler li...@eitanadler.com wrote: On Tue, Sep 6, 2011 at 6:44 PM, Manish Vachharajani mani...@lineratesystems.com wrote: Lots of libraries assume that time is fast because it is fast under Linux. Silly question, but why can't we make it fast too? -- Eitan Adler Manish ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org -- Rayson == Open Grid Scheduler - The Official Open Source Grid Engine http://gridscheduler.sourceforge.net/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: VMWare/Virtualbox virtio network drivers?
On Tue, Sep 6, 2011 at 7:50 PM, Stephen Hocking stephen.hock...@gmail.comwrote: Am wondering if anyone has done drivers the these sorts of network interfaces that are offered by VMWare Virtual box. I know that on some Linux VMs I run, performance went from 20MB/s to 30MB/s to an NFS server which I swicthed to the virtio network interfaces. There is this patch, but it didn't get committed for some reason. http://lists.freebsd.org/pipermail/freebsd-current/2011-January/022036.html -- Adam Vande More ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: excessive use of gettimeofday(2) and other syscalls
On Tue, Sep 6, 2011 at 7:15 PM, Rayson Ho raysonlo...@gmail.com wrote: There are some recent discussions on the freebsd-current list. The infrastructure is there to provide a common shared page for processes to mmap into the address space... but according to Kip's comment, libc support is not there yet: http://lists.freebsd.org/pipermail/freebsd-current/2011-June/025191.html Also, the kernel needs to update the variable in that shared page on each clock interrupt (depending on the resolution I believe), and I think that needs to be added too. This would address the system call overhead but this isn't even close to the bulk of the cost. Here is data for the average time for a call using various clocks (via clock_gettime) and gettimeofday. This is for a single process on a Xeon 5654 (2.4 GHz) machine running FreeBSD 7.3 for amd64. As you can see the system call cost is not the main issue as the _FAST calls complete at 7.7 million calls per second in a single process. CLOCK_MONOTONIC: 848716 per second CLOCK_MONOTONIC_FAST: 7.73687e+06 per second CLOCK_MONOTONIC_PRECISE: 848744 per second CLOCK_REALTIME: 850795 per second CLOCK_REALTIME_FAST: 7.81742e+06 per second CLOCK_REALTIME_PRECISE: 849574 per second CLOCK_UPTIME: 848736 per second CLOCK_UPTIME_FAST: 7.84147e+06 per second CLOCK_UPTIME_PRECISE(1 ways): 848637 per second gettimeofday: 848637 per second IMO, the time returned by gettimeofday does not need to be high precision. There are higher resolution time APIs on Linux and I believe the application programmers know when to use the slower but more accurate clock API. (At least in Grid Engine we only need a quick way of getting the current time, and we don't care if it is precise to the nanosecond range.) Indeed, time only returns time in seconds so precision per se is unnecessary. The question is are there any strange behaviors across cores that lead to incorrect behavior if the _FAST timers are used. That is the question . For example, is it possible (and if possible, ok) for a process to call time() and get 946,000,001, then get scheduled to another cpu, and then make another call to time and get 946,000,000, making it look like time has gone backwards. I don't think standard timers allow for this to happen but the _FAST timers may (I'm just not sure), especially on an overloaded VM where the kernel could be scheduled out for longer than a tick. See Linux security issue solution: http://lwn.net/Articles/446528/ See also the Google SoC idea: http://wiki.freebsd.org/IdeasPage#Timecounter_Performance_Improvements_.28GSoC.29 Rayson = Grid Engine / Open Grid Scheduler http://gridscheduler.sourceforge.net Manish ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: VMWare/Virtualbox virtio network drivers?
On 7 September 2011 09:32, Adam Vande More amvandem...@gmail.com wrote: On Tue, Sep 6, 2011 at 7:50 PM, Stephen Hocking stephen.hock...@gmail.comwrote: Am wondering if anyone has done drivers the these sorts of network interfaces that are offered by VMWare Virtual box. I know that on some Linux VMs I run, performance went from 20MB/s to 30MB/s to an NFS server which I swicthed to the virtio network interfaces. There is this patch, but it didn't get committed for some reason. http://lists.freebsd.org/pipermail/freebsd-current/2011-January/022036.html Has this been used/tested by others? I see a reply from you. Adrian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
