1. 30 10月, 2019 1 次提交
    • J
      io_uring: replace workqueue usage with io-wq · 561fb04a
      Jens Axboe 提交于
      Drop various work-arounds we have for workqueues:
      
      - We no longer need the async_list for tracking sequential IO.
      
      - We don't have to maintain our own mm tracking/setting.
      
      - We don't need a separate workqueue for buffered writes. This didn't
        even work that well to begin with, as it was suboptimal for multiple
        buffered writers on multiple files.
      
      - We can properly cancel pending interruptible work. This fixes
        deadlocks with particularly socket IO, where we cannot cancel them
        when the io_uring is closed. Hence the ring will wait forever for
        these requests to complete, which may never happen. This is different
        from disk IO where we know requests will complete in a finite amount
        of time.
      
      - Due to being able to cancel work interruptible work that is already
        running, we can implement file table support for work. We need that
        for supporting system calls that add to a process file table.
      
      - It gets us one step closer to adding async support for any system
        call.
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      561fb04a
  2. 16 10月, 2019 1 次提交
    • M
      arm64: use generic free_initrd_mem() · 899ee4af
      Mike Rapoport 提交于
      arm64 calls memblock_free() for the initrd area in its implementation of
      free_initrd_mem(), but this call has no actual effect that late in the boot
      process. By the time initrd is freed, all the reserved memory is managed by
      the page allocator and the memblock.reserved is unused, so the only purpose
      of the memblock_free() call is to keep track of initrd memory for debugging
      and accounting.
      
      Without the memblock_free() call the only difference between arm64 and the
      generic versions of free_initrd_mem() is the memory poisoning.
      
      Move memblock_free() call to the generic code, enable it there
      for the architectures that define ARCH_KEEP_MEMBLOCK and use the generic
      implementation of free_initrd_mem() on arm64.
      
      Tested-by: Anshuman Khandual <anshuman.khandual@arm.com>	#arm64
      Reviewed-by: NAnshuman Khandual <anshuman.khandual@arm.com>
      Acked-by: NWill Deacon <will@kernel.org>
      Signed-off-by: NMike Rapoport <rppt@linux.ibm.com>
      Signed-off-by: NCatalin Marinas <catalin.marinas@arm.com>
      899ee4af
  3. 25 9月, 2019 3 次提交
  4. 16 9月, 2019 2 次提交
  5. 13 9月, 2019 1 次提交
    • D
      vfs: Convert ramfs, shmem, tmpfs, devtmpfs, rootfs to use the new mount API · f3235626
      David Howells 提交于
      Convert the ramfs, shmem, tmpfs, devtmpfs and rootfs filesystems to the new
      internal mount API as the old one will be obsoleted and removed.  This
      allows greater flexibility in communication of mount parameters between
      userspace, the VFS and the filesystem.
      
      See Documentation/filesystems/mount_api.txt for more information.
      
      Note that tmpfs is slightly tricky as it can contain embedded commas, so it
      can't be trivially split up using strsep() to break on commas in
      generic_parse_monolithic().  Instead, tmpfs has to supply its own generic
      parser.
      
      However, if tmpfs changes, then devtmpfs and rootfs, which are wrappers
      around tmpfs or ramfs, must change too - and thus so must ramfs, so these
      had to be converted also.
      
      [AV: rewritten]
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      cc: Hugh Dickins <hughd@google.com>
      cc: linux-mm@kvack.org
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      f3235626
  6. 12 9月, 2019 2 次提交
  7. 10 9月, 2019 1 次提交
  8. 06 9月, 2019 2 次提交
  9. 04 9月, 2019 1 次提交
    • M
      kbuild,arc: add CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE_O3 for ARC · 15f5db60
      Masahiro Yamada 提交于
      arch/arc/Makefile overrides -O2 with -O3. This is the only user of
      ARCH_CFLAGS. There is no user of ARCH_CPPFLAGS or ARCH_AFLAGS.
      My plan is to remove ARCH_{CPP,A,C}FLAGS after refactoring the ARC
      Makefile.
      
      Currently, ARC has no way to enable -Wmaybe-uninitialized because both
      -O3 and -Os disable it. Enabling it will be useful for compile-testing.
      This commit allows allmodconfig (, which defaults to -O2) to enable it.
      
      Add CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE_O3=y to all the defconfig files
      in arch/arc/configs/ in order to keep the current config settings.
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Acked-by: NVineet Gupta <vgupta@synopsys.com>
      15f5db60
  10. 03 9月, 2019 1 次提交
    • P
      sched/uclamp: Extend CPU's cgroup controller · 2480c093
      Patrick Bellasi 提交于
      The cgroup CPU bandwidth controller allows to assign a specified
      (maximum) bandwidth to the tasks of a group. However this bandwidth is
      defined and enforced only on a temporal base, without considering the
      actual frequency a CPU is running on. Thus, the amount of computation
      completed by a task within an allocated bandwidth can be very different
      depending on the actual frequency the CPU is running that task.
      The amount of computation can be affected also by the specific CPU a
      task is running on, especially when running on asymmetric capacity
      systems like Arm's big.LITTLE.
      
      With the availability of schedutil, the scheduler is now able
      to drive frequency selections based on actual task utilization.
      Moreover, the utilization clamping support provides a mechanism to
      bias the frequency selection operated by schedutil depending on
      constraints assigned to the tasks currently RUNNABLE on a CPU.
      
      Giving the mechanisms described above, it is now possible to extend the
      cpu controller to specify the minimum (or maximum) utilization which
      should be considered for tasks RUNNABLE on a cpu.
      This makes it possible to better defined the actual computational
      power assigned to task groups, thus improving the cgroup CPU bandwidth
      controller which is currently based just on time constraints.
      
      Extend the CPU controller with a couple of new attributes uclamp.{min,max}
      which allow to enforce utilization boosting and capping for all the
      tasks in a group.
      
      Specifically:
      
      - uclamp.min: defines the minimum utilization which should be considered
      	      i.e. the RUNNABLE tasks of this group will run at least at a
      	      minimum frequency which corresponds to the uclamp.min
      	      utilization
      
      - uclamp.max: defines the maximum utilization which should be considered
      	      i.e. the RUNNABLE tasks of this group will run up to a
      	      maximum frequency which corresponds to the uclamp.max
      	      utilization
      
      These attributes:
      
      a) are available only for non-root nodes, both on default and legacy
         hierarchies, while system wide clamps are defined by a generic
         interface which does not depends on cgroups. This system wide
         interface enforces constraints on tasks in the root node.
      
      b) enforce effective constraints at each level of the hierarchy which
         are a restriction of the group requests considering its parent's
         effective constraints. Root group effective constraints are defined
         by the system wide interface.
         This mechanism allows each (non-root) level of the hierarchy to:
         - request whatever clamp values it would like to get
         - effectively get only up to the maximum amount allowed by its parent
      
      c) have higher priority than task-specific clamps, defined via
         sched_setattr(), thus allowing to control and restrict task requests.
      
      Add two new attributes to the cpu controller to collect "requested"
      clamp values. Allow that at each non-root level of the hierarchy.
      Keep it simple by not caring now about "effective" values computation
      and propagation along the hierarchy.
      
      Update sysctl_sched_uclamp_handler() to use the newly introduced
      uclamp_mutex so that we serialize system default updates with cgroup
      relate updates.
      Signed-off-by: NPatrick Bellasi <patrick.bellasi@arm.com>
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Reviewed-by: NMichal Koutny <mkoutny@suse.com>
      Acked-by: NTejun Heo <tj@kernel.org>
      Cc: Alessio Balsini <balsini@android.com>
      Cc: Dietmar Eggemann <dietmar.eggemann@arm.com>
      Cc: Joel Fernandes <joelaf@google.com>
      Cc: Juri Lelli <juri.lelli@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Morten Rasmussen <morten.rasmussen@arm.com>
      Cc: Paul Turner <pjt@google.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Quentin Perret <quentin.perret@arm.com>
      Cc: Rafael J . Wysocki <rafael.j.wysocki@intel.com>
      Cc: Steve Muckle <smuckle@google.com>
      Cc: Suren Baghdasaryan <surenb@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Todd Kjos <tkjos@google.com>
      Cc: Vincent Guittot <vincent.guittot@linaro.org>
      Cc: Viresh Kumar <viresh.kumar@linaro.org>
      Link: https://lkml.kernel.org/r/20190822132811.31294-2-patrick.bellasi@arm.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      2480c093
  11. 29 8月, 2019 1 次提交
  12. 28 8月, 2019 1 次提交
  13. 22 8月, 2019 1 次提交
  14. 20 8月, 2019 3 次提交
    • W
      Revert "init/Kconfig: Fix infinite Kconfig recursion on PPC" · 2d122942
      Will Deacon 提交于
      This reverts commit 71c67a31.
      
      Commit 117acf5c ("powerpc/Makefile: Always pass --synthetic to nm if
      supported") removed the only conditional definition of $(NM), so we can
      revert our temporary bodge to avoid Kconfig recursion and go back to
      passing $(NM) through to the 'tools-support-relr.sh' when detecting
      support for RELR relocations.
      Signed-off-by: NWill Deacon <will@kernel.org>
      2d122942
    • D
      lockdown: Enforce module signatures if the kernel is locked down · 49fcf732
      David Howells 提交于
      If the kernel is locked down, require that all modules have valid
      signatures that we can verify.
      
      I have adjusted the errors generated:
      
       (1) If there's no signature (ENODATA) or we can't check it (ENOPKG,
           ENOKEY), then:
      
           (a) If signatures are enforced then EKEYREJECTED is returned.
      
           (b) If there's no signature or we can't check it, but the kernel is
      	 locked down then EPERM is returned (this is then consistent with
      	 other lockdown cases).
      
       (2) If the signature is unparseable (EBADMSG, EINVAL), the signature fails
           the check (EKEYREJECTED) or a system error occurs (eg. ENOMEM), we
           return the error we got.
      
      Note that the X.509 code doesn't check for key expiry as the RTC might not
      be valid or might not have been transferred to the kernel's clock yet.
      
       [Modified by Matthew Garrett to remove the IMA integration. This will
        be replaced with integration with the IMA architecture policy
        patchset.]
      Signed-off-by: NDavid Howells <dhowells@redhat.com>
      Signed-off-by: NMatthew Garrett <matthewgarrett@google.com>
      Reviewed-by: NKees Cook <keescook@chromium.org>
      Cc: Jessica Yu <jeyu@kernel.org>
      Signed-off-by: NJames Morris <jmorris@namei.org>
      49fcf732
    • M
      security: Support early LSMs · e6b1db98
      Matthew Garrett 提交于
      The lockdown module is intended to allow for kernels to be locked down
      early in boot - sufficiently early that we don't have the ability to
      kmalloc() yet. Add support for early initialisation of some LSMs, and
      then add them to the list of names when we do full initialisation later.
      Early LSMs are initialised in link order and cannot be overridden via
      boot parameters, and cannot make use of kmalloc() (since the allocator
      isn't initialised yet).
      
      (Fixed by Stephen Rothwell to include a stub to fix builds when
      !CONFIG_SECURITY)
      Signed-off-by: NMatthew Garrett <mjg59@google.com>
      Acked-by: NKees Cook <keescook@chromium.org>
      Acked-by: NCasey Schaufler <casey@schaufler-ca.com>
      Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: NJames Morris <jmorris@namei.org>
      e6b1db98
  15. 14 8月, 2019 1 次提交
  16. 07 8月, 2019 1 次提交
    • W
      init/Kconfig: Fix infinite Kconfig recursion on PPC · 71c67a31
      Will Deacon 提交于
      Commit 5cf896fb ("arm64: Add support for relocating the kernel with
      RELR relocations") introduced CONFIG_TOOLS_SUPPORT_RELR, which checks
      for RELR support in the toolchain as part of the kernel configuration.
      During this procedure, "$(NM)" is invoked to see if it supports the new
      relocation format, however PowerPC conditionally overrides this variable
      in the architecture Makefile in order to pass '--synthetic' when
      targetting PPC64.
      
      This conditional override causes Kconfig to recurse forever, since
      CONFIG_TOOLS_SUPPORT_RELR cannot be determined without $(NM) being
      defined, but that in turn depends on CONFIG_PPC64:
      
        $ make ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu-
        scripts/kconfig/conf  --syncconfig Kconfig
        scripts/kconfig/conf  --syncconfig Kconfig
        scripts/kconfig/conf  --syncconfig Kconfig
        [...]
      
      In this particular case, it looks like PowerPC may be able to pass
      '--synthetic' unconditionally to nm or even drop it altogether. While
      that is being resolved, let's just bodge the RELR check by picking up
      $(NM) directly from the environment in whatever state it happens to be
      in.
      
      Cc: Peter Collingbourne <pcc@google.com>
      Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
      Suggested-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Signed-off-by: NWill Deacon <will@kernel.org>
      71c67a31
  17. 06 8月, 2019 1 次提交
  18. 05 8月, 2019 1 次提交
  19. 01 8月, 2019 1 次提交
  20. 17 7月, 2019 1 次提交
  21. 15 7月, 2019 2 次提交
  22. 13 7月, 2019 1 次提交
    • A
      mm: init: report memory auto-initialization features at boot time · 23a5c8cb
      Alexander Potapenko 提交于
      Print the currently enabled stack and heap initialization modes.
      
      Stack initialization is enabled by a config flag, while heap
      initialization is configured at boot time with defaults being set in the
      config.  It's more convenient for the user to have all information about
      these hardening measures in one place at boot, so the user can reason
      about the expected behavior of the running system.
      
      The possible options for stack are:
       - "all" for CONFIG_INIT_STACK_ALL;
       - "byref_all" for CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL;
       - "byref" for CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF;
       - "__user" for CONFIG_GCC_PLUGIN_STRUCTLEAK_USER;
       - "off" otherwise.
      
      Depending on the values of init_on_alloc and init_on_free boottime options
      we also report "heap alloc" and "heap free" as "on"/"off".
      
      In the init_on_free mode initializing pages at boot time may take a while,
      so print a notice about that as well.  This depends on how much memory is
      installed, the memory bandwidth, etc.  On a relatively modern x86 system,
      it takes about 0.75s/GB to wipe all memory:
      
        [    0.418722] mem auto-init: stack:byref_all, heap alloc:off, heap free:on
        [    0.419765] mem auto-init: clearing system memory may take some time...
        [   12.376605] Memory: 16408564K/16776672K available (14339K kernel code, 1397K rwdata, 3756K rodata, 1636K init, 11460K bss, 368108K reserved, 0K cma-reserved)
      
      Link: http://lkml.kernel.org/r/20190617151050.92663-3-glider@google.comSigned-off-by: NAlexander Potapenko <glider@google.com>
      Suggested-by: NKees Cook <keescook@chromium.org>
      Acked-by: NKees Cook <keescook@chromium.org>
      Cc: Christoph Lameter <cl@linux.com>
      Cc: Dmitry Vyukov <dvyukov@google.com>
      Cc: James Morris <jmorris@namei.org>
      Cc: Jann Horn <jannh@google.com>
      Cc: Kostya Serebryany <kcc@google.com>
      Cc: Laura Abbott <labbott@redhat.com>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
      Cc: Matthew Wilcox <willy@infradead.org>
      Cc: Nick Desaulniers <ndesaulniers@google.com>
      Cc: Randy Dunlap <rdunlap@infradead.org>
      Cc: Sandeep Patil <sspatil@android.com>
      Cc: "Serge E. Hallyn" <serge@hallyn.com>
      Cc: Souptick Joarder <jrdr.linux@gmail.com>
      Cc: Marco Elver <elver@google.com>
      Cc: Kaiwan N Billimoria <kaiwan@kaiwantech.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      23a5c8cb
  23. 09 7月, 2019 1 次提交
  24. 08 7月, 2019 2 次提交
    • M
      kbuild: compile-test exported headers to ensure they are self-contained · d6fc9fcb
      Masahiro Yamada 提交于
      Multiple people have suggested compile-testing UAPI headers to ensure
      they can be really included from user-space. "make headers_check" is
      obviously not enough to catch bugs, and we often leak unresolved
      references to user-space.
      
      Use the new header-test-y syntax to implement it. Please note exported
      headers are compile-tested with a completely different set of compiler
      flags. The header search path is set to $(objtree)/usr/include since
      exported headers should not include unexported ones.
      
      We use -std=gnu89 for the kernel space since the kernel code highly
      depends on GNU extensions. On the other hand, UAPI headers should be
      written in more standardized C, so they are compiled with -std=c90.
      This will emit errors if C++ style comments, the keyword 'inline', etc.
      are used. Please use C style comments (/* ... */), '__inline__', etc.
      in UAPI headers.
      
      There is additional compiler requirement to enable this test because
      many of UAPI headers include <stdlib.h>, <sys/ioctl.h>, <sys/time.h>,
      etc. directly or indirectly. You cannot use kernel.org pre-built
      toolchains [1] since they lack <stdlib.h>.
      
      I reused CONFIG_CC_CAN_LINK to check the system header availability.
      The intention is slightly different, but a compiler that can link
      userspace programs provide system headers.
      
      For now, a lot of headers need to be excluded because they cannot
      be compiled standalone, but this is a good start point.
      
      [1] https://mirrors.edge.kernel.org/pub/tools/crosstool/index.htmlSigned-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Reviewed-by: NSam Ravnborg <sam@ravnborg.org>
      d6fc9fcb
    • M
      init/Kconfig: add CONFIG_CC_CAN_LINK · 1a927fd3
      Masahiro Yamada 提交于
      Currently, scripts/cc-can-link.sh is run just for BPFILTER_UMH, but
      defining CC_CAN_LINK will be useful in other places.
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      1a927fd3
  25. 05 7月, 2019 3 次提交
    • A
      mnt_init(): call shmem_init() unconditionally · 037f11b4
      Al Viro 提交于
      No point having two call sites (earlier in init_rootfs() from
      mnt_init() in case we are going to use shmem-style rootfs,
      later from do_basic_setup() unconditionally), along with the
      logics in shmem_init() itself to make the second call a no-op...
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      037f11b4
    • A
      don't bother with registering rootfs · fd3e007f
      Al Viro 提交于
      init_mount_tree() can get to rootfs_fs_type directly and that simplifies
      a lot of things.  We don't need to register it, we don't need to look
      it up *and* we don't need to bother with preventing subsequent userland
      mounts.  That's the way we should've done that from the very beginning.
      
      There is a user-visible change, namely the disappearance of "rootfs"
      from /proc/filesystems.  Note that it's been unmountable all along
      and it didn't show up in /proc/mounts; however, it *is* a user-visible
      change and theoretically some script might've been using its presence
      in /proc/filesystems to tell 2.4.11+ from earlier kernels.
      
      *IF* any complaints about behaviour change do show up, we could fake
      it in /proc/filesystems.  I very much doubt we'll have to, though.
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      fd3e007f
    • A
      init_rootfs(): don't bother with init_ramfs_fs() · 14a253ce
      Al Viro 提交于
      the only thing done by the latter is making ramfs visible
      to mount(2); we don't need it there - rootfs is separate
      and, in fact, made visible to mount(2) in the same init_rootfs().
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      14a253ce
  26. 29 6月, 2019 1 次提交
    • G
      initramfs: fix populate_initrd_image() section mismatch · 4ada1e81
      Geert Uytterhoeven 提交于
      With gcc-4.6.3:
      
          WARNING: vmlinux.o(.text.unlikely+0x140): Section mismatch in reference from the function populate_initrd_image() to the variable .init.ramfs.info:__initramfs_size
          The function populate_initrd_image() references
          the variable __init __initramfs_size.
          This is often because populate_initrd_image lacks a __init
          annotation or the annotation of __initramfs_size is wrong.
      
          WARNING: vmlinux.o(.text.unlikely+0x14c): Section mismatch in reference from the function populate_initrd_image() to the function .init.text:unpack_to_rootfs()
          The function populate_initrd_image() references
          the function __init unpack_to_rootfs().
          This is often because populate_initrd_image lacks a __init
          annotation or the annotation of unpack_to_rootfs is wrong.
      
          WARNING: vmlinux.o(.text.unlikely+0x198): Section mismatch in reference from the function populate_initrd_image() to the function .init.text:xwrite()
          The function populate_initrd_image() references
          the function __init xwrite().
          This is often because populate_initrd_image lacks a __init
          annotation or the annotation of xwrite is wrong.
      
      Indeed, if the compiler decides not to inline populate_initrd_image(), a
      warning is generated.
      
      Fix this by adding the missing __init annotations.
      
      Link: http://lkml.kernel.org/r/20190617074340.12779-1-geert@linux-m68k.org
      Fixes: 7c184ecd ("initramfs: factor out a helper to populate the initrd image")
      Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      4ada1e81
  27. 25 6月, 2019 1 次提交
    • P
      sched/uclamp: Add CPU's clamp buckets refcounting · 69842cba
      Patrick Bellasi 提交于
      Utilization clamping allows to clamp the CPU's utilization within a
      [util_min, util_max] range, depending on the set of RUNNABLE tasks on
      that CPU. Each task references two "clamp buckets" defining its minimum
      and maximum (util_{min,max}) utilization "clamp values". A CPU's clamp
      bucket is active if there is at least one RUNNABLE tasks enqueued on
      that CPU and refcounting that bucket.
      
      When a task is {en,de}queued {on,from} a rq, the set of active clamp
      buckets on that CPU can change. If the set of active clamp buckets
      changes for a CPU a new "aggregated" clamp value is computed for that
      CPU. This is because each clamp bucket enforces a different utilization
      clamp value.
      
      Clamp values are always MAX aggregated for both util_min and util_max.
      This ensures that no task can affect the performance of other
      co-scheduled tasks which are more boosted (i.e. with higher util_min
      clamp) or less capped (i.e. with higher util_max clamp).
      
      A task has:
         task_struct::uclamp[clamp_id]::bucket_id
      to track the "bucket index" of the CPU's clamp bucket it refcounts while
      enqueued, for each clamp index (clamp_id).
      
      A runqueue has:
         rq::uclamp[clamp_id]::bucket[bucket_id].tasks
      to track how many RUNNABLE tasks on that CPU refcount each
      clamp bucket (bucket_id) of a clamp index (clamp_id).
      It also has a:
         rq::uclamp[clamp_id]::bucket[bucket_id].value
      to track the clamp value of each clamp bucket (bucket_id) of a clamp
      index (clamp_id).
      
      The rq::uclamp::bucket[clamp_id][] array is scanned every time it's
      needed to find a new MAX aggregated clamp value for a clamp_id. This
      operation is required only when it's dequeued the last task of a clamp
      bucket tracking the current MAX aggregated clamp value. In this case,
      the CPU is either entering IDLE or going to schedule a less boosted or
      more clamped task.
      The expected number of different clamp values configured at build time
      is small enough to fit the full unordered array into a single cache
      line, for configurations of up to 7 buckets.
      
      Add to struct rq the basic data structures required to refcount the
      number of RUNNABLE tasks for each clamp bucket. Add also the max
      aggregation required to update the rq's clamp value at each
      enqueue/dequeue event.
      
      Use a simple linear mapping of clamp values into clamp buckets.
      Pre-compute and cache bucket_id to avoid integer divisions at
      enqueue/dequeue time.
      Signed-off-by: NPatrick Bellasi <patrick.bellasi@arm.com>
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Alessio Balsini <balsini@android.com>
      Cc: Dietmar Eggemann <dietmar.eggemann@arm.com>
      Cc: Joel Fernandes <joelaf@google.com>
      Cc: Juri Lelli <juri.lelli@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Morten Rasmussen <morten.rasmussen@arm.com>
      Cc: Paul Turner <pjt@google.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Quentin Perret <quentin.perret@arm.com>
      Cc: Rafael J . Wysocki <rafael.j.wysocki@intel.com>
      Cc: Steve Muckle <smuckle@google.com>
      Cc: Suren Baghdasaryan <surenb@google.com>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Todd Kjos <tkjos@google.com>
      Cc: Vincent Guittot <vincent.guittot@linaro.org>
      Cc: Viresh Kumar <viresh.kumar@linaro.org>
      Link: https://lkml.kernel.org/r/20190621084217.8167-2-patrick.bellasi@arm.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      69842cba
  28. 21 6月, 2019 1 次提交
  29. 15 6月, 2019 1 次提交