title: How does USER_HZ solve the jiffy scaling issue?
body: <p>As I understand, the <code>USER_HZ</code> constant was added in Linux 2.6 to solve the issues arising from the expectations of the <code>HZ</code> value in user-space: in previous versions of Linux, changing the <code>HZ</code> value may cause values in user-space applications to be unintentionally scaled.</p>
  
  <p>I'm confused about how the <code>USER_HZ</code> constant solves this scaling problem. For example, say a user-space application converts jiffies to seconds:</p>
  
  <pre class="lang-c prettyprint-override"><code>long MY_HZ = sysconf(_SC_CLK_TCK);
  
  /* num_jiffies acquired from /proc but
   * simplified to 1000 here for clarity */
  long num_jiffies = 1000;
  
  long num_seconds = num_jiffies / MY_HZ;
  </code></pre>
  
  <p>Since the user-space application is determining the <code>HZ</code> value via a <code>sysconf</code> call, wouldn't this prevent a scaling issue?</p>
  
  <p>If on the other hand, the user-space applications did have the <code>HZ</code> value <em>hard-coded</em> into their source, how would a <code>USER_HZ</code> constant prevent a scaling issue -- the user-space applications would be using their <em>hard-coded</em> constants rather than the system's <code>USER_HZ</code>, and there's no guarantee the <em>hard-coded</em> constants matches <code>USER_HZ</code>?</p>
  
  <p>Furthermore, are all clock tick values available to user-space (e.g. <code>/proc</code>) already scaled to <code>USER_HZ</code>? How does a user-space program know whether a value in <em>jiffies</em> is scaled to <code>HZ</code> or <code>USER_HZ</code>?</p>