1. 10 Jan, 2006 1 commit
  2. 27 Jul, 2005 1 commit
  3. 29 Jun, 2005 1 commit
  4. 05 May, 2005 1 commit
    • Paulo Marques's avatar
      [PATCH] setitimer timer expires too early · b7e4e853
      Paulo Marques authored
      It seems that the code responsible for this is in kernel/itimer.c:126:
      	p->signal->real_timer.expires = jiffies + interval;
      If you request an interval of, lets say 900 usecs, the interval given by
      timeval_to_jiffies will be 1.
      If you request this when we are half-way between two timer ticks, the
      interval will only give 400 usecs.
      If we want to guarantee that we never ever give intervals less than
      requested, the simple solution would be to change that to:
      	p->signal->real_timer.expires = jiffies + interval + 1;
      This however will produce pathological cases, like having a idle system
      being requested 1 ms timeouts will give systematically 2 ms timeouts,
      whereas currently it simply gives a few usecs less than 1 ms.
      The complex (and more computationally expensive) solution would be to
      check the gettimeofday time, and compute the correct number of jiffies.
      This way, if we request a 300 usecs timer 200 usecs inside the timer
      tick, we can wait just one tick, but not if we are 800 usecs inside the
      tick. This would also mean that we would have to lock preemption during
      these computations to avoid races, etc.
      I've searched the archives but couldn't find this particular issue being
      discussed before.
      Attached is a patch to do the simple solution, in case anybody thinks
      that it should be used.
      Signed-Off-By: default avatarPaulo Marques <pmarques@grupopie.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
  5. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      Let it rip!