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
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
maxi
Christine Tran wrote:
The zones.cpu-shares rctl has a set of threshhold actions: none, deny
and signal=. Say if I set the action as signal=TERM, who actually gets
signaled? Is it the process in the zone that's currently queuing to get
on CPU, or is it zoneadmd (which presumably will pass it b
IIRC for zones.cpu-shares the action is ignored. Something about "all infinite
resources behave like this," i.e. CPU cycles aren't bounded. To the scheduler,
you can always get more cycles if you're willint to wait a nanosecond or six.
Which makes sense to me - under what conditions would a p
Christine Tran wrote:
The zones.cpu-shares rctl has a set of threshhold actions: none, deny
and signal=. Say if I set the action as signal=TERM, who actually gets
signaled? Is it the process in the zone that's currently queuing to get
on CPU, or is it zoneadmd (which presumably will pass it b
The zones.cpu-shares rctl has a set of threshhold actions: none, deny
and signal=. Say if I set the action as signal=TERM, who actually gets
signaled? Is it the process in the zone that's currently queuing to get
on CPU, or is it zoneadmd (which presumably will pass it back?)
I've always use
