1. 23 11月, 2005 1 次提交
  2. 09 11月, 2005 1 次提交
    • A
      [PATCH] cpu hotplug: fix locking in cpufreq drivers · 90d45d17
      Ashok Raj 提交于
      When calling target drivers to set frequency, we take cpucontrol lock.
      When we modified the code to accomodate CPU hotplug, there was an attempt
      to take a double lock of cpucontrol leading to a deadlock.  Since the
      current thread context is already holding the cpucontrol lock, we dont need
      to make another attempt to acquire it.
      
      Now we leave a trace in current->flags indicating current thread already is
      under cpucontrol lock held, so we dont attempt to do this another time.
      
      Thanks to Andrew Morton for the beating:-)
      
      From: Brice Goglin <Brice.Goglin@ens-lyon.org>
      
        Build fix
      
      (akpm: this patch is still unpleasant.  Ashok continues to look for a cleaner
      solution, doesn't he?  ;))
      Signed-off-by: NAshok Raj <ashok.raj@intel.com>
      Signed-off-by: NBrice Goglin <Brice.Goglin@ens-lyon.org>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      90d45d17
  3. 02 11月, 2005 1 次提交
  4. 31 10月, 2005 2 次提交
    • A
      [PATCH] create and destroy cpufreq sysfs entries based on cpu notifiers · c32b6b8e
      Ashok Raj 提交于
      cpufreq entries in sysfs should only be populated when CPU is online state.
       When we either boot with maxcpus=x and then boot the other cpus by echoing
      to sysfs online file, these entries should be created and destroyed when
      CPU_DEAD is notified.  Same treatement as cache entries under sysfs.
      
      We place the processor in the lowest frequency, so hw managed P-State
      transitions can still work on the other threads to save power.
      
      Primary goal was to just make these directories appear/disapper dynamically.
      
      There is one in this patch i had to do, which i really dont like myself but
      probably best if someone handling the cpufreq infrastructure could give
      this code right treatment if this is not acceptable.  I guess its probably
      good for the first cut.
      
      - Converting lock_cpu_hotplug()/unlock_cpu_hotplug() to disable/enable preempt.
        The locking was smack in the middle of the notification path, when the
        hotplug is already holding the lock. I tried another solution to avoid this
        so avoid taking locks if we know we are from notification path. The solution
        was getting very ugly and i decided this was probably good for this iteration
        until someone who understands cpufreq could do a better job than me.
      
      (akpm: export cpucontrol to GPL modules: drivers/cpufreq/cpufreq_stats.c now
      does lock_cpu_hotplug())
      Signed-off-by: NAshok Raj <ashok.raj@intel.com>
      Signed-off-by: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
      Cc: Dave Jones <davej@codemonkey.org.uk>
      Cc: Zwane Mwaikambo <zwane@holomorphy.com>
      Cc: Greg KH <greg@kroah.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      c32b6b8e
    • A
      [PATCH] Remove cpu_sys_devices in cpufreq subsystem. · d434fca7
      Ashok Raj 提交于
      cpu_sys_devices is redundant with the new API get_cpu_sysdev().  So nuking
      this usage since its not needed.
      Signed-off-by: NAshok Raj <ashok.raj@intel.com>
      Signed-off-by: NVenkatesh Pallipadi <venkatesh.pallipadi@intel.com>
      Cc: Dave Jones <davej@codemonkey.org.uk>
      Cc: Zwane Mwaikambo <zwane@holomorphy.com>
      Cc: Greg KH <greg@kroah.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      d434fca7
  5. 28 10月, 2005 2 次提交
  6. 21 10月, 2005 1 次提交
  7. 21 9月, 2005 1 次提交
    • D
      [CPUFREQ] Avoid the ondemand cpufreq governor to use a too high frequency for stats. · df8b59be
      Dave Jones 提交于
      The problem is in the ondemand governor, there is a periodic measurement
      of the CPU usage. This CPU usage is updated by the scheduler after every
      tick (basically, by adding 1 either to "idle" or to "user" or to
      "system"). So if the frequency of the governor is too high, the stat
      will be meaningless (as mostly no number have changed).
      
      So this patch checks that the measurements are separated by at least 10
      ticks. It means that by default, stats will have about 5% error (20
      ticks). Of course those numbers can be argued but, IMHO, they look sane.
      The patch also includes a small clean-up to check more explictly the
      result of the conversion from ns to µs being null.
      
      Let's note that (on x86) this has never been really needed before 2.6.13
      because HZ was always 1000. Now that HZ can be 100, some CPU might be
      affected by this problem. For instance when HZ=100, the centrino ,which
      has a 10µs transition latency, would lead to the governor allowing to
      read stats every tick (10ms)!
      Signed-off-by: NEric Piel <eric.piel@tremplin-utc.net>
      Signed-off-by: NDave Jones <davej@redhat.com>
      df8b59be
  8. 01 9月, 2005 1 次提交
  9. 29 7月, 2005 1 次提交
  10. 08 7月, 2005 1 次提交
  11. 21 6月, 2005 1 次提交
  12. 01 6月, 2005 14 次提交
  13. 02 5月, 2005 1 次提交
  14. 29 4月, 2005 1 次提交
  15. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      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!
      1da177e4