On Wed Feb 23 11, John Baldwin wrote: > On Tuesday, February 22, 2011 4:50:36 pm Alexander Best wrote: > > On Tue Feb 22 11, Brandon Gooch wrote: > > > On Tue, Feb 22, 2011 at 2:31 PM, Alexander Best <arundel_at_freebsd.org> > wrote: > > > > On Tue Feb 22 11, Garrett Cooper wrote: > > > >> On Tue, Feb 22, 2011 at 2:10 AM, Eir Nym <eirnym_at_gmail.com> wrote: > > > >> > On 22 February 2011 11:15, Garrett Cooper <yanegomi_at_gmail.com> wrote: > > > >> >> I don't know what to say, but r218938 screams with flash videos > > > >> >> (native Linux speed). Not sure if it's the new binutils or if it's > the > > > >> >> new linuxulator patches, but I can run multiple instances of youtube > > > >> >> in parallel (5 total with other miscellaneous flash animation) > without > > > >> >> it totally lagging out Firefox/X11, and it appears to close the > > > >> >> instances of firefox properly now. Hopefully this version fares > better > > > >> >> than r218113 did (I think I hit a kernel bug after 2 weeks uptime, > > > >> >> where my system just hardlocked for no apparent reason). > > > >> >> Anyhow, hope others have similar results. > > > >> >> Cheers! > > > >> >> -Garrett > > > >> >> > > > >> >> $ uname -a > > > >> >> FreeBSD bayonetta.local 9.0-CURRENT FreeBSD 9.0-CURRENT #0 r218938M: > > > >> >> Mon Feb 21 23:10:51 PST 2011 > > > >> >> gcooper_at_bayonetta.local:/usr/obj/usr/src/sys/BAYONETTA amd64 > > > >> > > > > >> > Which FlashPlayer version do you test? Adobe has made significant > > > >> > performance changes in 10.2 (from 10.1). You can search for > StageVideo > > > >> > performance to learn more about. Youtube already use them since 10.2 > > > >> > beta > > > >> > > > >> linux-f10-flashplugin-10.1r102.65 . The performance increases are > > > >> claimed to be "up to 85%" on the Stage Video site, but I'm seeing a > > > >> more than 200% increase (now it actually scales between multiple > > > >> instances, instead of croaks with one instance, tiling up and down the > > > >> screen when moving the window slider for instance or switching tabs). > > > >> Besides, it seems like it needs external support from the video > > > >> driver, and I'm not sure that that bridge exists in the linuxulator. > > > >> Also, it looks like npviewer.bin still hangs to resources on until > > > >> Firefox closes (or I kill it :)..), so something still needs to be > > > >> resolved there, but that isn't a regression (it's acted that way for > > > >> ages), and shouldn't be too hard to do. > > > > > > > > i think the problem with npviewer.bin having to be killed by hand is a > futex > > > > issue in combination with a high number of threads. this is the output > of a > > > > test from darren hart's futex test suite under freebsd 9.0: > > > > > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=1 > > > > Result: 18622 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=2 > > > > Result: 15469 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=3 > > > > Result: 12713 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=4 > > > > Result: 12247 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=5 > > > > Result: 11814 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=6 > > > > Result: 13468 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=8 > > > > Result: 12061 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=10 > > > > Result: 12854 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=12 > > > > Result: 12999 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=16 > > > > Result: 12402 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=24 > > > > Result: 9815 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=32 > > > > Result: 8518 Kiter/s > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=64 > > > > ERROR: Resource temporarily unavailable: pthread_create > > > > Result: ERROR > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=128 > > > > ERROR: Resource temporarily unavailable: pthread_create > > > > Result: ERROR > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=256 > > > > ERROR: Resource temporarily unavailable: pthread_create > > > > Result: ERROR > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=512 > > > > ERROR: Resource temporarily unavailable: pthread_create > > > > Result: ERROR > > > > futex_wait: Measure FUTEX_WAIT operations per second > > > > Arguments: iterations=100000000 threads=1024 > > > > ERROR: Resource temporarily unavailable: pthread_create > > > > Result: ERROR > > > > > > > > cheers. > > > > alex > > > > > > Have you found any method or workaround to mitigate this issue? > > > > no. i've increased the kern.threads.max_threads_per_proc value, but that had > > no effect. so it seems to be a bug in the linuxulator's futex > implementation. > > You can try http://www.freebsd.org/~jhb/patches/futex_share.patch > > Not sure if it will solve your issue, but it might help if multiple > processes (Linux processes, not just multiple FreeBSD processes > masquerading as threads in a single Linux process) are involved. no unfortunately. i don't think the failures with threads 64-1024 are futex related, since linux_mmap2() returns -ENOMEN and thus seems responsible. however even with your patch i still see lots of linux_sys_futex() calls failing with -EAGAIN in the range of 2-32 threads. it seems nanosleep is failing. either because some linux timespecs aren't converted to their *BSD equivalents properly or another reason could be that CLOCK_MONOTONIC and CLOCK_REALTIME aren't yet honoured in linux_futex.c, but simply discarded. the actual place in linux_futex.c where EAGAIN gets handed over to the linuxulator is here: static int futex_sleep(struct futex *f, struct waiting_proc *wp, int timeout) { int error; FUTEX_ASSERT_LOCKED(f); LINUX_CTR4(sys_futex, "futex_sleep enter uaddr %p wp %p timo %d ref %d", f->f_uaddr, wp, timeout, f->f_refcount); error = sx_sleep(wp, &f->f_lck, PCATCH, "futex", timeout); // HERE EAGAIN GETS RETURNED cheers. alex > > -- > John Baldwin -- a13xReceived on Wed Feb 23 2011 - 12:45:19 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:11 UTC