Mercurial > illumos > illumos-gate
changeset 4939:d8c715038e31
6593891 CPU Caps code incorrectly assumes that cap stays on
author | akolb |
---|---|
date | Thu, 23 Aug 2007 21:39:46 -0700 |
parents | 2f612e2f1503 |
children | 2c1b097e634e |
files | usr/src/uts/common/disp/cpucaps.c |
diffstat | 1 files changed, 11 insertions(+), 1 deletions(-) [+] |
line wrap: on
line diff
--- a/usr/src/uts/common/disp/cpucaps.c Thu Aug 23 20:40:28 2007 -0700 +++ b/usr/src/uts/common/disp/cpucaps.c Thu Aug 23 21:39:46 2007 -0700 @@ -953,6 +953,9 @@ * * Do not adjust for more than one tick worth of time. * + * It is possible that the project cap is being disabled while this routine is + * executed. This should not cause any issues since the association between the + * thread and its project is protected by thread lock. */ static void caps_charge_adjust(kthread_id_t t, caps_sc_t *csc) @@ -962,7 +965,7 @@ hrtime_t usage_delta; ASSERT(THREAD_LOCK_HELD(t)); - ASSERT(PROJECT_IS_CAPPED(kpj)); + ASSERT(kpj->kpj_cpucap != NULL); /* Get on-CPU time since birth of a thread */ new_usage = mstate_thread_onproc_time(t); @@ -1006,6 +1009,13 @@ * Charge thread's project and return True if project or zone should be * penalized because its project or zone is exceeding its cap. Also sets * TS_PROJWAITQ or TS_ZONEWAITQ in this case. + * + * It is possible that the project cap is being disabled while this routine is + * executed. This should not cause any issues since the association between the + * thread and its project is protected by thread lock. It will still set + * TS_PROJECTWAITQ/TS_ZONEWAITQ in this case but cpucaps_enforce will not place + * anything on the blocked wait queue. + * */ boolean_t cpucaps_charge(kthread_id_t t, caps_sc_t *csc, cpucaps_charge_t charge_type)