No, as far as I can tell, the kmem allocs in fork use KMEM_SLEEP. This
means that they're guaranteed to return memory, and will sleep until
some becomes available.
EAGAIN covers a lot of different errors in fork.
EAGAIN A resource control or limit on the total number
of processes, tasks or LWPs under execution by a
single user, task, project, or zone has been
exceeded, or the total amount of system memory
available is temporarily insufficient to duplicate
this process.
According to the manpage, quoted above, this can occur when you've
exceeded rctls or process limits, or hit a problem allocating a resource
needed for the process. A quick look through cfork, the kernel's common
fork routine, shows that we'll return EAGAIN for a wide class of errors.
An as_dup() that fails but isn't an ENOMEM, no available lwpids,
exceeding resource limits, all generate an EAGAIN error.
DTrace has a feature called speculative tracing that is particularly
helpful when looking at these kinds of failures. It allows you to
examine just the code paths that are causing the failure. There's an
example that uses open64 here:
http://wikis.sun.com/display/DTrace/Speculative+Tracing
You could adapt this to use forksys instead. This would allow you to
see just where in the kernel your fork is actually failing.
-j
On Fri, Nov 14, 2008 at 06:37:21AM -0800, tester wrote:
> I was wondering if a fork failure with EAGAIN will manifest as an allocation
> failure in vmem, if so how to see that and if there is a specifc cache that
> can be tweaked. At present the only cache that is reporting any failure is
>
> kmem_lp 1002438656 1002438656 239 1858
>
> thanks
> --
> This message posted from opensolaris.org
> _______________________________________________
> perf-discuss mailing list
> perf-discuss@opensolaris.org
_______________________________________________
perf-discuss mailing list
perf-discuss@opensolaris.org
