* reducing the sampling rate, we need to make the new value effective
  * immediately.
  *
- * On the other hand, if new rate is larger than the old, then we may evaluate
- * the load too soon, and it might we worth updating sample_delay_ns then as
- * well.
- *
  * This must be called with dbs_data->mutex held, otherwise traversing
  * policy_dbs_list isn't safe.
  */
                 * really doesn't matter.  If the read returns a value that's
                 * too big, the sample will be skipped, but the next invocation
                 * of dbs_update_util_handler() (when the update has been
-                * completed) will take a sample.  If the returned value is too
-                * small, the sample will be taken immediately, but that isn't a
-                * problem, as we want the new rate to take effect immediately
-                * anyway.
+                * completed) will take a sample.
                 *
                 * If this runs in parallel with dbs_work_handler(), we may end
                 * up overwriting the sample_delay_ns value that it has just
-                * written, but the difference should not be too big and it will
-                * be corrected next time a sample is taken, so it shouldn't be
-                * significant.
+                * written, but it will be corrected next time a sample is
+                * taken, so it shouldn't be significant.
                 */
-               gov_update_sample_delay(policy_dbs, dbs_data->sampling_rate);
+               gov_update_sample_delay(policy_dbs, 0);
                mutex_unlock(&policy_dbs->timer_mutex);
        }