> >From my limited understanding, there are 2 kinds of
> speculation
> related failures that are seen:
> Failures due to insufficient number of buffers (no
> speculative buffer
> available) and failures due to using a buffer that is
> busy getting
> discarded/committed (available buffer(s) still busy)
> For the former consider increasing the number of
> buffers with the
> nspec option. For the latter, consider setting the
> CPU cleanrate to
> value beyond the default (101)
> The "Abort due to systemic unresponsiveness"
> indicates heavy load.
> This if addressed will probably not throw the "error
> on enabled probe"
> error assuming data access is happening right.
>
> When is the speculative buffer created? When is it
> committed? Can the
> paths being speculated be reduced?
>
> -Shiv
>
syscall::fork*:entry
{
self->spec = speculation();
}
syscall::fork*:return
/self->spec/
{
speculate(self->spec);
}
syscall::fork*:return
/self->spec && errno != 0/
{
/*
* If errno is non-zero, we want to commit the speculation.
*/
commit(self->spec);
self->spec = 0;
}
syscall::fork*:return
/self->spec && errno == 0/
{
/*
* If errno is not set, we discard the speculation.
*/
discard(self->spec);
self->spec = 0;
}
As I mentioned we want to capture code path for a fork failre. Any changes
needed? I am more interested in knowing why it aborted? Sar o/p tell around 40%
cpu idle (of-course the sar granularity is less). Thanks for any comments.
--
This message posted from opensolaris.org
_______________________________________________
dtrace-discuss mailing list
[email protected]
