Re: [rfc] bind per-cpu timeout threads to each CPU
On 20 February 2014 11:17, John Baldwin wrote: > (A further variant of this would be to divorce cpu0's swi from the > catch-all softclock and let the catch-all softclock float, but bind > all the per-cpu swis) I like this idea. If something (eg per-CPU TCP timers, if it's turned on) makes a very specific decision about the CPU then it should be fixed. Otherwise a lot of the underlying assumptions for things like RSS just aren't guaranteed to hold. It could also perhaps extend to some abstract pool of CPUs later, if we wanted to do things like one flowing swi per socket or whatnot when we start booting on 1024 core boxes... -a ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
DNS records being cached?
Well, explain this if you can: I have unbound running in a jail and host /etc/resolv.conf entry for "name server" is . I recently changed the A rec to a domain, then did "unbound-control flush ". Now, drill from jail shows new IP, while drill from host shows old IP. - FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS -- View this message in context: http://freebsd.1045724.n5.nabble.com/DNS-records-being-cached-tp5887735.html Sent from the freebsd-current mailing list archive at Nabble.com. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [rfc] bind per-cpu timeout threads to each CPU
On Wednesday, February 19, 2014 4:02:54 pm John Baldwin wrote: > On Wednesday, February 19, 2014 3:04:51 pm Adrian Chadd wrote: > > On 19 February 2014 11:59, Alexander Motin wrote: > > > > >> So if we're moving towards supporting (among others) a pcbgroup / RSS > > >> hash style work load distribution across CPUs to minimise > > >> per-connection lock contention, we really don't want the scheduler to > > >> decide it can schedule things on other CPUs under enough pressure. > > >> That'll just make things worse. > > > > > True, though it is also not obvious that putting second thread on CPU run > > > queue is better then executing it right now on another core. > > > > Well, it depends if you're trying to optimise for "run all runnable > > tasks as quickly as possible" or "run all runnable tasks in contexts > > that minimise lock contention." > > > > The former sounds great as long as there's no real lock contention > > going on. But as you add more chances for contention (something like > > "100,000 concurrent TCP flows") then you may end up having your TCP > > timer firing stuff interfere with more TXing or RXing on the same > > connection. > > > > Chasing this stuff down is a pain, because it only really shows up > > when you're doing lots of concurrency. > > > > I'm happy to make this a boot-time option and leave it off for the > > time being. How's that? > > I think having it be a tunable would be good. OTOH, I could also > see another option which would be to pin all clock threads except > for the "default" one by default and only have the option control > whether or not the default thread is pinned to CPU 0 as callers > who use callout_on() are explicitly asking to run the callout on a > specific CPU. (A further variant of this would be to divorce cpu0's swi from the catch-all softclock and let the catch-all softclock float, but bind all the per-cpu swis) -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: x11/kde4-workspace: build fails on 11.-0CURRENT due to c++: error: linker command failed: /usr/local/lib/libGLESv2.so: undefined reference to `_glapi_get_dispatch'
On Thu, 20 Feb 2014 08:49:35 +0100 "O. Hartmann" wrote: > > The port x11/kde-workspace (kde-workspace-4.10.5_2 on my > installation) fails to be updated and therefore a bunch of very > important applications (i.e. devel/kdevelop) do not work anymore. > > The build/update of x11/kde4-workspace failst due to: > > [...] > [ 98%] Built target kwin > gmake[4]: Entering directory > `/usr/ports/x11/kde4-workspace/work/.build' Scanning dependencies of > target kwin_gles gmake[4]: Leaving directory > `/usr/ports/x11/kde4-workspace/work/.build' gmake[4]: Entering > directory `/usr/ports/x11/kde4-workspace/work/.build' [ 98%] Building > CXX object kwin/CMakeFiles/kwin_gles.dir/kwin_gles_dummy.cpp.o > Linking CXX executable kwin_gles [ 98%] Building CXX object > kmenuedit/CMakeFiles/kdeinit_kmenuedit.dir/basictab.cpp.o > > ===>>> /usr/local/lib/libGLESv2.so: undefined reference to > `_glapi_get_dispatch' ===>>>/usr/local/lib/libGLESv2.so: undefined > reference to `_glapi_Dispatch' > > c++: error: linker command failed with exit code 1 (use -v to see > invocation) gmake[4]: *** [kwin/kwin_gles] Error 1 > gmake[4]: Leaving directory > `/usr/ports/x11/kde4-workspace/work/.build' gmake[3]: *** > [kwin/CMakeFiles/kwin_gles.dir/all] Error 2 gmake[3]: *** Waiting for > unfinished jobs [ 98%] Building CXX object > kmenuedit/CMakeFiles/kdeinit_kmenuedit.dir/treeview.cpp.o [ 98%] > Building CXX object > kmenuedit/CMakeFiles/kdeinit_kmenuedit.dir/kmenuedit.cpp.o [ 98%] > Building CXX object > kmenuedit/CMakeFiles/kdeinit_kmenuedit.dir/menufile.cpp.o [100%] > Building CXX object > kmenuedit/CMakeFiles/kdeinit_kmenuedit.dir/menuinfo.cpp.o [100%] > Building CXX object > kmenuedit/CMakeFiles/kdeinit_kmenuedit.dir/khotkeys.cpp.o [100%] > Building CXX object > kmenuedit/CMakeFiles/kdeinit_kmenuedit.dir/kmenueditadaptor.cpp.o > [100%] Building CXX object > kmenuedit/CMakeFiles/kdeinit_kmenuedit.dir/khotkeys_interface.cpp.o > Linking CXX shared library ../lib/libkdeinit4_kmenuedit.so gmake[4]: > Leaving directory > `/usr/ports/x11/kde4-workspace/wographics/libglesvrk/.build' [100%] > Built target kdeinit_kmenuedit gmake[3]: Leaving directory > `/usr/ports/x11/kde4-workspace/work/.build' gmake[2]: *** [all] Error > 2 gmake[2]: Leaving directory > `/usr/ports/x11/kde4-workspace/work/.build' ===> Compilation failed > unexpectedly. Try to set MAKE_JOBS_UNSAFE=yes and rebuild before > reporting the failure to the maintainer. *** Error code 1 > > Stop. > make[1]: stopped in /usr/ports/x11/kde4-workspace > > > I tried to reinstall port graphics/libglesv2 via > > portmaster -f graphics/libglesv2 > > to ensure no fault at this port, but the error still remains. > > Do I miss something? In the past, I tried to find all the ports which > needed to be recompiled due to C++ library version bump-up. > > Is there a fast solution for this? What is going wrong? > > Thanks in advance, > > Oliver Hartmann As I checked recently, this is also true for FreeBSD 9.2-STABLE #0 r261834: Thu Feb 13 16:04:55 CET 2014 amd64 (LLVM/CLANG 3.3). oh signature.asc Description: PGP signature
