1. 20 Oct, 2023 2 commits
  2. 18 Oct, 2023 1 commit
  3. 16 Oct, 2023 1 commit
  4. 13 Oct, 2023 3 commits
  5. 12 Oct, 2023 1 commit
  6. 11 Oct, 2023 2 commits
  7. 10 Oct, 2023 7 commits
  8. 09 Oct, 2023 9 commits
  9. 07 Oct, 2023 7 commits
  10. 05 Oct, 2023 1 commit
    • Xuewen Yan's avatar
      cpufreq: schedutil: Update next_freq when cpufreq_limits change · 9e0bc36a
      Xuewen Yan authored
      When cpufreq's policy is 'single', there is a scenario that will
      cause sg_policy's next_freq to be unable to update.
      
      When the CPU's util is always max, the cpufreq will be max,
      and then if we change the policy's scaling_max_freq to be a
      lower freq, indeed, the sg_policy's next_freq need change to
      be the lower freq, however, because the cpu_is_busy, the next_freq
      would keep the max_freq.
      
      For example:
      
      The cpu7 is a single CPU:
      
        unisoc:/sys/devices/system/cpu/cpufreq/policy7 # while true;do done& [1] 4737
        unisoc:/sys/devices/system/cpu/cpufreq/policy7 # taskset -p 80 4737
        pid 4737's current affinity mask: ff
        pid 4737's new affinity mask: 80
        unisoc:/sys/devices/system/cpu/cpufreq/policy7 # cat scaling_max_freq
        2301000
        unisoc:/sys/devices/system/cpu/cpufreq/policy7 # cat scaling_cur_freq
        2301000
        unisoc:/sys/devices/system/cpu/cpufreq/policy7 # echo 2171000 > scaling_max_freq
        unisoc:/sys/devices/system/cpu/cpufreq/policy7 # cat scaling_max_freq
        2171000
      
      At this time, the sg_policy's next_freq would stay at 2301000, which
      is wrong.
      
      To fix this, add a check for the ->need_freq_update flag.
      
      [ mingo: Clarified the changelog. ]
      Co-developed-by: default avatarGuohua Yan <guohua.yan@unisoc.com>
      Signed-off-by: default avatarXuewen Yan <xuewen.yan@unisoc.com>
      Signed-off-by: default avatarGuohua Yan <guohua.yan@unisoc.com>
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Acked-by: default avatar"Rafael J. Wysocki" <rafael@kernel.org>
      Link: https://lore.kernel.org/r/20230719130527.8074-1-xuewen.yan@unisoc.com
      9e0bc36a
  11. 03 Oct, 2023 3 commits
  12. 02 Oct, 2023 3 commits
    • Kir Kolyshkin's avatar
      sched/headers: Move 'struct sched_param' out of uapi, to work around glibc/musl breakage · d844fe65
      Kir Kolyshkin authored
      Both glibc and musl define 'struct sched_param' in sched.h, while kernel
      has it in uapi/linux/sched/types.h, making it cumbersome to use
      sched_getattr(2) or sched_setattr(2) from userspace.
      
      For example, something like this:
      
      	#include <sched.h>
      	#include <linux/sched/types.h>
      
      	struct sched_attr sa;
      
      will result in "error: redefinition of ‘struct sched_param’" (note the
      code doesn't need sched_param at all -- it needs struct sched_attr
      plus some stuff from sched.h).
      
      The situation is, glibc is not going to provide a wrapper for
      sched_{get,set}attr, thus the need to include linux/sched_types.h
      directly, which leads to the above problem.
      
      Thus, the userspace is left with a few sub-par choices when it wants to
      use e.g. sched_setattr(2), such as maintaining a copy of struct
      sched_attr definition, or using some other ugly tricks.
      
      OTOH, 'struct sched_param' is well known, defined in POSIX, and it won't
      be ever changed (as that would break backward compatibility).
      
      So, while 'struct sched_param' is indeed part of the kernel uapi,
      exposing it the way it's done now creates an issue, and hiding it
      (like this patch does) fixes that issue, hopefully without creating
      another one: common userspace software rely on libc headers, and as
      for "special" software (like libc), it looks like glibc and musl
      do not rely on kernel headers for 'struct sched_param' definition
      (but let's Cc their mailing lists in case it's otherwise).
      
      The alternative to this patch would be to move struct sched_attr to,
      say, linux/sched.h, or linux/sched/attr.h (the new file).
      
      Oh, and here is the previous attempt to fix the issue:
      
        https://lore.kernel.org/all/20200528135552.GA87103@google.com/
      
      While I support Linus arguments, the issue is still here
      and needs to be fixed.
      
      [ mingo: Linus is right, this shouldn't be needed - but on the other
               hand I agree that this header is not really helpful to
      	 user-space as-is. So let's pretend that
      	 <uapi/linux/sched/types.h> is only about sched_attr, and
      	 call this commit a workaround for user-space breakage
      	 that it in reality is ... Also, remove the Fixes tag. ]
      Signed-off-by: default avatarKir Kolyshkin <kolyshkin@gmail.com>
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: https://lore.kernel.org/r/20230808030357.1213829-1-kolyshkin@gmail.com
      d844fe65
    • Cyril Hrubis's avatar
      83494dc5
    • Cyril Hrubis's avatar
      sched/rt/docs: Clarify & fix sched_rt_* sysctl docs · e6dbdd8f
      Cyril Hrubis authored
      - Describe explicitly that sched_rt_runtime_us is allocated from
        sched_rt_period_us and hence always less or equal to that value.
      
      - The limit for sched_rt_runtime_us is not INT_MAX-1, but rather it's
        limited by the value of sched_rt_period_us. If sched_rt_period_us is
        INT_MAX then sched_rt_runtime_us can be set to INT_MAX as well.
      Signed-off-by: default avatarCyril Hrubis <chrubis@suse.cz>
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Link: https://lore.kernel.org/r/20231002115553.3007-3-chrubis@suse.cz
      e6dbdd8f