Date: Fri, 4 Feb 2011 22:15:24 +1030 From: "Daniel O'Connor" <doconnor@gsoft.com.au> To: Ivan Voras <ivoras@freebsd.org> Cc: freebsd-hackers@freebsd.org Subject: Re: Scheduler question Message-ID: <AA0DA14A-A8E5-48C5-AABE-ECCB02C59D19@gsoft.com.au> In-Reply-To: <iignas$kbc$1@dough.gmane.org> References: <53A394ED-7C2E-4E4B-A9A7-CB5F1B27DBE3@gsoft.com.au> <iignas$kbc$1@dough.gmane.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. >=20 > 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: >=20 > 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. Thanks :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AA0DA14A-A8E5-48C5-AABE-ECCB02C59D19>