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.
Menno
_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org
