Thanks. I have some follow-up questions > 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. which system memory is being referred here? Is there a hard formula in use here? Shouldn't paging kick-in? > 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+Traci > ng > > 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 > OK. I go ahead and this up Thanks. > 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 > hanks > > -- > > This message posted from opensolaris.org > > _______________________________________________ > > perf-discuss mailing list > > perf-discuss@opensolaris.org > _______________________________________________ > perf-discuss mailing list > perf-discuss@opensolaris.org -- This message posted from opensolaris.org _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
