Christine Tran wrote:
Menno Lageman wrote:

Nobody gets signaled, as 'signal' (and 'deny' for that matter) are not valid actions for zone.cpu-shares. This is because cpu-shares is not a limit that can be exceeded in the sense that for instance project.max-filedescriptor can be exceeded. Once a zone is at it's maximum allowed cpu share, it won't get scheduled so it can't exceed the limit.

If you want to know what actions are possible for a rctl, see the rctladm(1M) output:

# rctladm zone.cpu-shares
zone.cpu-shares syslog=n/a [ no-basic no-deny no-signal no-syslog count ]

'no-deny' tells you that 'deny' is not a valid action for this rctl. Ditto for 'no-signal' and 'no-syslog'.

Great!  Thank you for clearing that up.  Same question, for zone.max-lwps.

# rctladm zone.max-lwps
zone.max-lwps               syslog=off     [ no-basic count ]

I guess, then, I can have action=signal=TERM? Who gets signaled, the process that wants another lwp, or zoneadmd, or something else? Not that I want to kill that process, I just want to know the mechanism. 'deny' would make more sense here? What would 'none' do, nothing, nullifying the limit?

The requesting process is signaled. See resource_controls(5):

     Local actions are taken on a process that attempts to exceed
     the  control  value. For each threshold value that is placed
     on a  resource  control,  you  can  associate  one  or  more
     actions. There are three types of local actions: none, deny,
and signal=.

And 'deny' would usually make more sense, giving the requesting process the chance to back off or maybe perform some cleanup like lowering the amount of lwps it uses (for applications that create a pool of threads).

The 'none' action will not deny the request, but if the global syslog action was set on this control, a syslog message would be logged when the limit is exceeded ('zone.max-lwps exceeded by pid nnn in zone z1'). This can be useful when trying to find reasonable limits.

zones-discuss mailing list

Reply via email to