Re: time stops in vmware

2012-04-10 Thread Daniel Braniss
On Sun, 08 Apr 2012 02:11:25 -0500, Daniel Braniss da...@cs.huji.ac.il wrote: Hi All There was some mention before that time stops under vmware, and now it's happened to me :-) the clock stopped now, the system is responsive, but eg sleep 1 never finishes. Is there a

Re: mlockall() on freebsd 7.2 + amd64 returns EAGAIN

2012-04-10 Thread Konstantin Belousov
On Mon, Apr 09, 2012 at 07:37:11PM -0700, Sushanth Rai wrote: Hello, I have a simple program that links with the math library. The only thing that program does is to call mlockall(MCL_CURRENT | MCL_FUTURE). This call to mlockall fails with EAGAIN. I figured out that kernel vm_fault() is

Re: Startvation of realtime piority threads

2012-04-10 Thread John Baldwin
On Monday, April 09, 2012 4:32:24 pm Sushanth Rai wrote: I'm using stock 7.2. The priorities as defined in priority.h are in this range: /* * Priorities range from 0 to 255, but differences of less then 4 (RQ_PPQ) * are insignificant. Ranges are as follows: * * Interrupt threads:

Re: problems with mmap() and disk caching

2012-04-10 Thread Alan Cox
On 04/09/2012 10:26, John Baldwin wrote: On Thursday, April 05, 2012 11:54:31 am Alan Cox wrote: On 04/04/2012 02:17, Konstantin Belousov wrote: On Tue, Apr 03, 2012 at 11:02:53PM +0400, Andrey Zonov wrote: Hi, I open the file, then call mmap() on the whole file and get pointer, then I work

Re: [RFT][patch] Scheduling for HTT and not only

2012-04-10 Thread Arnaud Lacombe
Hi, 2012/4/9 Alexander Motin m...@freebsd.org: [...] I have strong feeling that while this test may be interesting for profiling, it's own results in first place depend not from how fast scheduler is, but from the pipes capacity and other alike things. Can somebody hint me what except pipe

mlock/mlockall (was: Re: problems with mmap() and disk caching)

2012-04-10 Thread Dieter BSD
Andrey writes: Wired memory: kernel memory and yes, application may get wired memory through mlock()/mlockall(), but I haven't seen any real application which calls mlock(). Apps with real time considerations may need to lock memory to prevent having to wait for page/swap.

Re: [RFT][patch] Scheduling for HTT and not only

2012-04-10 Thread Alexander Motin
On 04/10/12 19:58, Arnaud Lacombe wrote: 2012/4/9 Alexander Motinm...@freebsd.org: [...] I have strong feeling that while this test may be interesting for profiling, it's own results in first place depend not from how fast scheduler is, but from the pipes capacity and other alike things. Can

Re: Startvation of realtime piority threads

2012-04-10 Thread Sushanth Rai
Thanks. I'll try to back port locally. Sushanth --- On Tue, 4/10/12, John Baldwin j...@freebsd.org wrote: From: John Baldwin j...@freebsd.org Subject: Re: Startvation of realtime piority threads To: Sushanth Rai sushanth_...@yahoo.com Cc: freebsd-hackers@freebsd.org Date: Tuesday, April

Re: [RFT][patch] Scheduling for HTT and not only

2012-04-10 Thread Alexander Motin
On 04/10/12 20:18, Alexander Motin wrote: On 04/10/12 19:58, Arnaud Lacombe wrote: 2012/4/9 Alexander Motinm...@freebsd.org: [...] I have strong feeling that while this test may be interesting for profiling, it's own results in first place depend not from how fast scheduler is, but from the

Re: [RFT][patch] Scheduling for HTT and not only

2012-04-10 Thread Arnaud Lacombe
Hi, On Tue, Apr 10, 2012 at 1:53 PM, Alexander Motin m...@freebsd.org wrote: On 04/10/12 20:18, Alexander Motin wrote: On 04/10/12 19:58, Arnaud Lacombe wrote: 2012/4/9 Alexander Motinm...@freebsd.org: [...] I have strong feeling that while this test may be interesting for profiling,

Re: [RFT][patch] Scheduling for HTT and not only

2012-04-10 Thread Alexander Motin
On 04/10/12 21:46, Arnaud Lacombe wrote: On Tue, Apr 10, 2012 at 1:53 PM, Alexander Motinm...@freebsd.org wrote: On 04/10/12 20:18, Alexander Motin wrote: On 04/10/12 19:58, Arnaud Lacombe wrote: 2012/4/9 Alexander Motinm...@freebsd.org: I have strong feeling that while this test may be

Re: [RFT][patch] Scheduling for HTT and not only

2012-04-10 Thread Mike Meyer
On Tue, 10 Apr 2012 12:58:00 -0400 Arnaud Lacombe lacom...@gmail.com wrote: Let me disagree on your conclusion. If OS A does a task in X seconds, and OS B does the same task in Y seconds, if Y X, then OS B is just not performing good enough. Others have pointed out one problem with this

Re: [RFT][patch] Scheduling for HTT and not only

2012-04-10 Thread Arnaud Lacombe
Hi, On Tue, Apr 10, 2012 at 4:05 PM, Mike Meyer m...@mired.org wrote: On Tue, 10 Apr 2012 12:58:00 -0400 Arnaud Lacombe lacom...@gmail.com wrote: Let me disagree on your conclusion. If OS A does a task in X seconds, and OS B does the same task in Y seconds, if Y X, then OS B is just not

Re: [RFT][patch] Scheduling for HTT and not only

2012-04-10 Thread Mike Meyer
On Tue, 10 Apr 2012 16:50:39 -0400 Arnaud Lacombe lacom...@gmail.com wrote: On Tue, Apr 10, 2012 at 4:05 PM, Mike Meyer m...@mired.org wrote: On Tue, 10 Apr 2012 12:58:00 -0400 Arnaud Lacombe lacom...@gmail.com wrote: Let me disagree on your conclusion. If OS A does a task in X seconds,

Re: time stops in vmware

2012-04-10 Thread Mark Felder
On Tue, 10 Apr 2012 03:04:10 -0500, Daniel Braniss da...@cs.huji.ac.il wrote: no, I can't recreate it, could you? We haven't seen this problem since FreeBSD 6.x. I can't recall how reproducible it was. ___ freebsd-hackers@freebsd.org mailing

Re: mlockall() on freebsd 7.2 + amd64 returns EAGAIN

2012-04-10 Thread Sushanth Rai
I don't know if that has anything to do with failure. The snippet of code that returns failure in vm_fault() is the following: if (fs.pindex = fs.object-size) {        unlock_and_deallocate(fs);        return (KERN_PROTECTION_FAILURE); } Any help would be appreciated. This

Re: mlockall() on freebsd 7.2 + amd64 returns EAGAIN

2012-04-10 Thread Konstantin Belousov
On Tue, Apr 10, 2012 at 06:33:44PM -0700, Sushanth Rai wrote: I don't know if that has anything to do with failure. The snippet of code that returns failure in vm_fault() is the following: if (fs.pindex = fs.object-size) {        unlock_and_deallocate(fs);        return