Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 05 Feb 2011 01:39:24 +0100
From:      Ivan Voras <ivoras@freebsd.org>
To:        freebsd-hackers@freebsd.org
Subject:   Re: Scheduler question
Message-ID:  <iii67s$ngs$1@dough.gmane.org>
In-Reply-To: <AA0DA14A-A8E5-48C5-AABE-ECCB02C59D19@gsoft.com.au>
References:  <53A394ED-7C2E-4E4B-A9A7-CB5F1B27DBE3@gsoft.com.au>	<iignas$kbc$1@dough.gmane.org> <AA0DA14A-A8E5-48C5-AABE-ECCB02C59D19@gsoft.com.au>

next in thread | previous in thread | raw e-mail | index | archive | help
On 04/02/2011 12:45, Daniel O'Connor wrote:
>
> On 04/02/2011, at 21:48, Ivan Voras wrote:
>>> I am wondering if this is a scheduler problem (or I am expecting too much :) in that it is not running my libusb thread reliably under load. The other possibility is that it is a USB issue, although I am looking at using isochronous transfers instead of bulk.
>>
>> I'm surprised this isn't complained about more often - I also regularly see that file system activity blocks other, non-file-using processes which are mostly CPU and memory intensive (but since I'm not running realtime things, it fell under the "good enough" category). Maybe there is kind of global-ish lock of some kind which the VM or the VFS hold which would interfere with normal operation of other processes (maybe when the processes use malloc() to grow their memory?).
>
> I guess for an interactive user anything less than 100msec is probably not noticeable unless it happens reasonably regularly when watching a video.
>
>> Could you try 2 things:
>>
>> 	1) instead of doing file IO, could you directly use a disk device (e.g. /dev/ad0), possibly with some more intensive utility than dd (e.g. "diskinfo -vt") and see if there is any difference?
>
> OK, I'll give it a shot.
>
>> 	2) if there is a difference in 1), try modifying your program to not use malloc() in the critical path (if applicable) and/or use mlock(2)?
>
> It doesn't allocate memory once it's going, everything is preallocated before the data transfer starts.
>
> I'll have a go with mlock() and see what happens.

Did you find anything interesting?




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?iii67s$ngs$1>