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. 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 _______________________________________________ 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"
