Re: [dtrace-discuss] Why am I getting drops?
From what I understand on this thread : http://forum.java.sun.com/thread.jspa?threadID=5133053tstart=30 there is a hardcoded limit in DTrace of 16M for the buffer size when you are not running as root. Why, why, why ?? -- This message posted from opensolaris.org ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] RES: Process in LCK / SLP (Please)
On Fri, Apr 18, 2008 at 02:40:15PM -0400, Jonathan Adams wrote: On Apr 18, 2008, at 1:03 PM, Kleyson Rios wrote: Hi przemol, Bellow output of plockstat for malloc and libumem. Both many locks. Why changing to libumem I didn't get less locks ? You're looking at Mutex hold statistics, which don't mean a lot (unless contention is caused by long hold times) The important thing for multi-threaded performance is *contention*. (Spinning and blocking) Those are the statistics you should be looking at. Both malloc and libumem use locks to protect their state; libumem just uses many locks, in order to reduce contention. So it seems Kleyson that I was wrong and rickey c weisner script is the way to go. Regards przemol -- http://przemol.blogspot.com/ -- Posluchaj najlepszych kawalkow w Sieci! http://link.interia.pl/f1da1 ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] Why am I getting drops?
On Mon, Apr 21, 2008 at 12:33:47AM -0700, Lars Bruun-Hansen wrote: there is a hardcoded limit in DTrace of 16M for the buffer size when you are not running as root. Why, why, why ?? We don't want to let non-root users exhaust system resources. A root user can change this by modifying dtrace_nonroot_maxsize via 'mdb -k' or by adding a set directive to /etc/system (check out system(4)). Adam -- Adam Leventhal, Fishworkshttp://blogs.sun.com/ahl ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] whatfor.d -- where's null pointer?
On Apr 21, 2008, at 11:00 AM, Adam Leventhal wrote: Either we need to use some temporary, probe-local variable (one that can't conflict with a user-defined variable), or we need to perform some element of optimization to the generated DIF. I've filed this bug: 6691541 curlwpsinfo-pr_stype races Adam Wow, that is a cool bug. If you choose to do some element of optimization, is it possible to guarantee every case will be correctly handled? I worry that it might be difficult to reason about the thread safety of code without explicit guarantees about how this is handled. James M ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] whatfor.d -- where's null pointer?
On Mon, Apr 21, 2008 at 11:00:29AM -0700, Adam Leventhal wrote: So curlwpsinfo-pr_stype can work and later fail. Looking at the translator for that field we see that it looks like this: pr_stype = T-t_sobj_ops ? T-t_sobj_ops-sobj_type : 0; This compiles to this DIF code: [...] We can see that we load the t_sobj_ops member once at offset 07 and then again at offset 17 (right before we load sobj_type at offset 18). The t_sobj_ops member can be set to NULL asynchronously from other threads so this double load introduces a window for the failure that you're seeing. Either we need to use some temporary, probe-local variable (one that can't conflict with a user-defined variable), or we need to perform some element of optimization to the generated DIF. In the world of LISP macros the macro writer would gensym a local variable (probe-local in this case) to deal with this sort of issue. Perhaps the DTrace translator facility needs a probe-local gensym feature. Nico -- ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] whatfor.d -- where's null pointer?
On Mon, Apr 21, 2008 at 01:54:16PM -0500, Nicolas Williams wrote: In the world of LISP macros the macro writer would gensym a local variable (probe-local in this case) to deal with this sort of issue. Perhaps the DTrace translator facility needs a probe-local gensym feature. Indeed, many languages have a construct to let you create a new scope; adding one to D might be a good idea. Adam -- Adam Leventhal, Fishworkshttp://blogs.sun.com/ahl ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] whatfor.d -- where's null pointer?
On Apr 21, 2008, at 1:04 PM, Adam Leventhal wrote: On Mon, Apr 21, 2008 at 11:45:25AM -0700, James McIlree wrote: Either we need to use some temporary, probe-local variable (one that can't conflict with a user-defined variable), or we need to perform some element of optimization to the generated DIF. I've filed this bug: 6691541 curlwpsinfo-pr_stype races If you choose to do some element of optimization, is it possible to guarantee every case will be correctly handled? I worry that it might be difficult to reason about the thread safety of code without explicit guarantees about how this is handled. The optimization would just be to perform the load once -- this is what most C compilers would do absent the volatile keyword. And I absolutely would not trust the C compiler in this case either :-). It's not required by spec to load once and only once, and there are times when it doesn't. James M ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
