1. 07 Dec, 2005 1 commit
    • Venkatesh Pallipadi's avatar
      [CPUFREQ] CPU frequency display in /proc/cpuinfo · 95235ca2
      Venkatesh Pallipadi authored
      What is the value shown in "cpu MHz" of /proc/cpuinfo when CPUs are capable of
      changing frequency?
      
      Today the answer is: It depends.
      On i386:
      SMP kernel - It is always the boot frequency
      UP kernel - Scales with the frequency change and shows that was last set.
      
      On x86_64:
      There is one single variable cpu_khz that gets written by all the CPUs. So,
      the frequency set by last CPU will be seen on /proc/cpuinfo of all the
      CPUs in the system. What you see also depends on whether you have constant_tsc
      capable CPU or not.
      
      On ia64:
      It is always boot time frequency of a particular CPU that gets displayed.
      
      The patch below changes this to:
      Show the last known frequency of the particular CPU, when cpufreq is present. If
      cpu doesnot support changing of frequency through cpufreq, then boot frequency
      will be shown. The patch affects i386, x86_64 and ia64 architectures.
      
      Signed-off-by: Venkatesh Pallipadi<venkatesh.pallipadi@intel.com>
      Signed-off-by: default avatarDave Jones <davej@redhat.com>
      95235ca2
  2. 01 Dec, 2005 1 commit
    • Alexander Clouter's avatar
      [PATCH] cpufreq_conservative/ondemand: invert meaning of 'ignore nice' · 001893cd
      Alexander Clouter authored
      The use of the 'ignore_nice' sysfs file is confusing to anyone using it.
      This removes the sysfs file 'ignore_nice' and in its place creates a
      'ignore_nice_load' entry that defaults to '0'; meaning nice'd processes
      _are_ counted towards the 'business' calculation.
      
      WARNING: this obvious breaks any userland tools that expected ignore_nice'
      to exist, to draw attention to this fact it was concluded on the mailing
      list that the entry should be removed altogether so the userland app breaks
      and so the author can build simple to detect workaround.  Having said that
      it seems currently very few tools even make use of this functionality; all
      I could find was a Gentoo Wiki entry.
      Signed-off-by: default avatarAlexander Clouter <alex-kernel@digriz.org.uk>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarDave Jones <davej@redhat.com>
      001893cd
  3. 28 Nov, 2005 1 commit
    • Ashok Raj's avatar
      [PATCH] clean up lock_cpu_hotplug() in cpufreq · a9d9baa1
      Ashok Raj authored
      There are some callers in cpufreq hotplug notify path that the lowest
      function calls lock_cpu_hotplug().  The lock is already held during
      cpu_up() and cpu_down() calls when the notify calls are broadcast to
      registered clients.
      
      Ideally if possible, we could disable_preempt() at the highest caller and
      make sure we dont sleep in the path down in cpufreq->driver_target() calls
      but the calls are so intertwined and cumbersome to cleanup.
      
      Hence we consistently use lock_cpu_hotplug() and unlock_cpu_hotplug() in
      all places.
      
       - Removed export of cpucontrol semaphore and made it static.
       - removed explicit uses of up/down with lock_cpu_hotplug()
         so we can keep track of the the callers in same thread context and
         just keep refcounts without calling a down() that causes a deadlock.
       - Removed current_in_hotplug() uses
       - Removed PF_HOTPLUG_CPU in sched.h introduced for the current_in_hotplug()
         temporary workaround.
      
      Tested with insmod of cpufreq_stat.ko, and logical online/offline
      to make sure we dont have any hang situations.
      Signed-off-by: default avatarAshok Raj <ashok.raj@intel.com>
      Cc: Zwane Mwaikambo <zwane@linuxpower.ca>
      Cc: Shaohua Li <shaohua.li@intel.com>
      Cc: "Siddha, Suresh B" <suresh.b.siddha@intel.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      a9d9baa1
  4. 22 Nov, 2005 1 commit
  5. 09 Nov, 2005 1 commit
    • Ashok Raj's avatar
      [PATCH] cpu hotplug: fix locking in cpufreq drivers · 90d45d17
      Ashok Raj authored
      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: default avatarAshok Raj <ashok.raj@intel.com>
      Signed-off-by: default avatarBrice Goglin <Brice.Goglin@ens-lyon.org>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      90d45d17
  6. 02 Nov, 2005 1 commit
  7. 31 Oct, 2005 2 commits
    • Ashok Raj's avatar
      [PATCH] create and destroy cpufreq sysfs entries based on cpu notifiers · c32b6b8e
      Ashok Raj authored
      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: default avatarAshok Raj <ashok.raj@intel.com>
      Signed-off-by: default avatarVenkatesh 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: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      c32b6b8e
    • Ashok Raj's avatar
      [PATCH] Remove cpu_sys_devices in cpufreq subsystem. · d434fca7
      Ashok Raj authored
      cpu_sys_devices is redundant with the new API get_cpu_sysdev().  So nuking
      this usage since its not needed.
      Signed-off-by: default avatarAshok Raj <ashok.raj@intel.com>
      Signed-off-by: default avatarVenkatesh 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: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      d434fca7
  8. 27 Oct, 2005 2 commits
  9. 20 Oct, 2005 1 commit
  10. 20 Sep, 2005 1 commit
    • Dave Jones's avatar
      [CPUFREQ] Avoid the ondemand cpufreq governor to use a too high frequency for stats. · df8b59be
      Dave Jones authored
      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: default avatarEric Piel <eric.piel@tremplin-utc.net>
      Signed-off-by: default avatarDave Jones <davej@redhat.com>
      df8b59be
  11. 01 Sep, 2005 1 commit
  12. 28 Jul, 2005 1 commit
  13. 08 Jul, 2005 1 commit
  14. 20 Jun, 2005 1 commit
  15. 01 Jun, 2005 14 commits
  16. 02 May, 2005 1 commit
  17. 29 Apr, 2005 1 commit
  18. 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!
      1da177e4