02 Nov, 2017

1 commit

  • Many source files in the tree are missing licensing information, which
    makes it harder for compliance tools to determine the correct license.

    By default all files without license information are under the default
    license of the kernel, which is GPL version 2.

    Update the files which contain no license information with the 'GPL-2.0'
    SPDX license identifier. The SPDX identifier is a legally binding
    shorthand, which can be used instead of the full boiler plate text.

    This patch is based on work done by Thomas Gleixner and Kate Stewart and
    Philippe Ombredanne.

    How this work was done:

    Patches were generated and checked against linux-4.14-rc6 for a subset of
    the use cases:
    - file had no licensing information it it.
    - file was a */uapi/* one with no licensing information in it,
    - file was a */uapi/* one with existing licensing information,

    Further patches will be generated in subsequent months to fix up cases
    where non-standard license headers were used, and references to license
    had to be inferred by heuristics based on keywords.

    The analysis to determine which SPDX License Identifier to be applied to
    a file was done in a spreadsheet of side by side results from of the
    output of two independent scanners (ScanCode & Windriver) producing SPDX
    tag:value files created by Philippe Ombredanne. Philippe prepared the
    base worksheet, and did an initial spot review of a few 1000 files.

    The 4.13 kernel was the starting point of the analysis with 60,537 files
    assessed. Kate Stewart did a file by file comparison of the scanner
    results in the spreadsheet to determine which SPDX license identifier(s)
    to be applied to the file. She confirmed any determination that was not
    immediately clear with lawyers working with the Linux Foundation.

    Criteria used to select files for SPDX license identifier tagging was:
    - Files considered eligible had to be source code files.
    - Make and config files were included as candidates if they contained >5
    lines of source
    - File already had some variant of a license header in it (even if
    Reviewed-by: Philippe Ombredanne
    Reviewed-by: Thomas Gleixner
    Signed-off-by: Greg Kroah-Hartman

    Greg Kroah-Hartman
     

17 Aug, 2017

1 commit

  • Implement MEMBARRIER_CMD_PRIVATE_EXPEDITED with IPIs using cpumask built
    from all runqueues for which current thread's mm is the same as the
    thread calling sys_membarrier. It executes faster than the non-expedited
    variant (no blocking). It also works on NOHZ_FULL configurations.

    Scheduler-wise, it requires a memory barrier before and after context
    switching between processes (which have different mm). The memory
    barrier before context switch is already present. For the barrier after
    context switch:

    * Our TSO archs can do RELEASE without being a full barrier. Look at
    x86 spin_unlock() being a regular STORE for example. But for those
    archs, all atomics imply smp_mb and all of them have atomic ops in
    switch_mm() for mm_cpumask(), and on x86 the CR3 load acts as a full
    barrier.

    * From all weakly ordered machines, only ARM64 and PPC can do RELEASE,
    the rest does indeed do smp_mb(), so there the spin_unlock() is a full
    barrier and we're good.

    * ARM64 has a very heavy barrier in switch_to(), which suffices.

    * PPC just removed its barrier from switch_to(), but appears to be
    talking about adding something to switch_mm(). So add a
    smp_mb__after_unlock_lock() for now, until this is settled on the PPC
    side.

    Changes since v3:
    - Properly document the memory barriers provided by each architecture.

    Changes since v2:
    - Address comments from Peter Zijlstra,
    - Add smp_mb__after_unlock_lock() after finish_lock_switch() in
    finish_task_switch() to add the memory barrier we need after storing
    to rq->curr. This is much simpler than the previous approach relying
    on atomic_dec_and_test() in mmdrop(), which actually added a memory
    barrier in the common case of switching between userspace processes.
    - Return -EINVAL when MEMBARRIER_CMD_SHARED is used on a nohz_full
    kernel, rather than having the whole membarrier system call returning
    -ENOSYS. Indeed, CMD_PRIVATE_EXPEDITED is compatible with nohz_full.
    Adapt the CMD_QUERY mask accordingly.

    Changes since v1:
    - move membarrier code under kernel/sched/ because it uses the
    scheduler runqueue,
    - only add the barrier when we switch from a kernel thread. The case
    where we switch from a user-space thread is already handled by
    the atomic_dec_and_test() in mmdrop().
    - add a comment to mmdrop() documenting the requirement on the implicit
    memory barrier.

    CC: Peter Zijlstra
    CC: Paul E. McKenney
    CC: Boqun Feng
    CC: Andrew Hunter
    CC: Maged Michael
    CC: gromer@google.com
    CC: Avi Kivity
    CC: Benjamin Herrenschmidt
    CC: Paul Mackerras
    CC: Michael Ellerman
    Signed-off-by: Mathieu Desnoyers
    Signed-off-by: Paul E. McKenney
    Tested-by: Dave Watson

    Mathieu Desnoyers
     

20 Jun, 2017

2 commits

  • Conflicts:
    kernel/sched/Makefile

    Pick up the waitqueue related renames - it didn't get much feedback,
    so it appears to be uncontroversial. Famous last words? ;-)

    Signed-off-by: Ingo Molnar

    Ingo Molnar
     
  • The wait_bit*() types and APIs are mixed into wait.h, but they
    are a pretty orthogonal extension of wait-queues.

    Furthermore, only about 50 kernel files use these APIs, while
    over 1000 use the regular wait-queue functionality.

    So clean up the main wait.h by moving the wait-bit functionality
    out of it, into a separate .h and .c file:

    include/linux/wait_bit.h for types and APIs
    kernel/sched/wait_bit.c for the implementation

    Update all header dependencies.

    This reduces the size of wait.h rather significantly, by about 30%.

    Cc: Linus Torvalds
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Cc: linux-kernel@vger.kernel.org
    Signed-off-by: Ingo Molnar

    Ingo Molnar
     

08 Jun, 2017

1 commit

  • The stop class is invoked through stop_machine only.
    This is dead code on UP builds.

    Signed-off-by: Nicolas Pitre
    Signed-off-by: Peter Zijlstra (Intel)
    Cc: Linus Torvalds
    Cc: Mike Galbraith
    Cc: Peter Zijlstra
    Cc: Thomas Gleixner
    Link: http://lkml.kernel.org/r/20170529210302.26868-3-nicolas.pitre@linaro.org
    Signed-off-by: Ingo Molnar

    Nicolas Pitre
     

08 Feb, 2017

1 commit


07 Feb, 2017

1 commit


02 Apr, 2016

1 commit

  • Add a new cpufreq scaling governor, called "schedutil", that uses
    scheduler-provided CPU utilization information as input for making
    its decisions.

    Doing that is possible after commit 34e2c555f3e1 (cpufreq: Add
    mechanism for registering utilization update callbacks) that
    introduced cpufreq_update_util() called by the scheduler on
    utilization changes (from CFS) and RT/DL task status updates.
    In particular, CPU frequency scaling decisions may be based on
    the the utilization data passed to cpufreq_update_util() by CFS.

    The new governor is relatively simple.

    The frequency selection formula used by it depends on whether or not
    the utilization is frequency-invariant. In the frequency-invariant
    case the new CPU frequency is given by

    next_freq = 1.25 * max_freq * util / max

    where util and max are the last two arguments of cpufreq_update_util().
    In turn, if util is not frequency-invariant, the maximum frequency in
    the above formula is replaced with the current frequency of the CPU:

    next_freq = 1.25 * curr_freq * util / max

    The coefficient 1.25 corresponds to the frequency tipping point at
    (util / max) = 0.8.

    All of the computations are carried out in the utilization update
    handlers provided by the new governor. One of those handlers is
    used for cpufreq policies shared between multiple CPUs and the other
    one is for policies with one CPU only (and therefore it doesn't need
    to use any extra synchronization means).

    The governor supports fast frequency switching if that is supported
    by the cpufreq driver in use and possible for the given policy.
    In the fast switching case, all operations of the governor take
    place in its utilization update handlers. If fast switching cannot
    be used, the frequency switch operations are carried out with the
    help of a work item which only calls __cpufreq_driver_target()
    (under a mutex) to trigger a frequency update (to a value already
    computed beforehand in one of the utilization update handlers).

    Currently, the governor treats all of the RT and DL tasks as
    "unknown utilization" and sets the frequency to the allowed
    maximum when updated from the RT or DL sched classes. That
    heavy-handed approach should be replaced with something more
    subtle and specifically targeted at RT and DL tasks.

    The governor shares some tunables management code with the
    "ondemand" and "conservative" governors and uses some common
    definitions from cpufreq_governor.h, but apart from that it
    is stand-alone.

    Signed-off-by: Rafael J. Wysocki
    Acked-by: Viresh Kumar
    Acked-by: Peter Zijlstra (Intel)

    Rafael J. Wysocki
     

23 Mar, 2016

1 commit

  • kcov provides code coverage collection for coverage-guided fuzzing
    (randomized testing). Coverage-guided fuzzing is a testing technique
    that uses coverage feedback to determine new interesting inputs to a
    system. A notable user-space example is AFL
    (http://lcamtuf.coredump.cx/afl/). However, this technique is not
    widely used for kernel testing due to missing compiler and kernel
    support.

    kcov does not aim to collect as much coverage as possible. It aims to
    collect more or less stable coverage that is function of syscall inputs.
    To achieve this goal it does not collect coverage in soft/hard
    interrupts and instrumentation of some inherently non-deterministic or
    non-interesting parts of kernel is disbled (e.g. scheduler, locking).

    Currently there is a single coverage collection mode (tracing), but the
    API anticipates additional collection modes. Initially I also
    implemented a second mode which exposes coverage in a fixed-size hash
    table of counters (what Quentin used in his original patch). I've
    dropped the second mode for simplicity.

    This patch adds the necessary support on kernel side. The complimentary
    compiler support was added in gcc revision 231296.

    We've used this support to build syzkaller system call fuzzer, which has
    found 90 kernel bugs in just 2 months:

    https://github.com/google/syzkaller/wiki/Found-Bugs

    We've also found 30+ bugs in our internal systems with syzkaller.
    Another (yet unexplored) direction where kcov coverage would greatly
    help is more traditional "blob mutation". For example, mounting a
    random blob as a filesystem, or receiving a random blob over wire.

    Why not gcov. Typical fuzzing loop looks as follows: (1) reset
    coverage, (2) execute a bit of code, (3) collect coverage, repeat. A
    typical coverage can be just a dozen of basic blocks (e.g. an invalid
    input). In such context gcov becomes prohibitively expensive as
    reset/collect coverage steps depend on total number of basic
    blocks/edges in program (in case of kernel it is about 2M). Cost of
    kcov depends only on number of executed basic blocks/edges. On top of
    that, kernel requires per-thread coverage because there are always
    background threads and unrelated processes that also produce coverage.
    With inlined gcov instrumentation per-thread coverage is not possible.

    kcov exposes kernel PCs and control flow to user-space which is
    insecure. But debugfs should not be mapped as user accessible.

    Based on a patch by Quentin Casasnovas.

    [akpm@linux-foundation.org: make task_struct.kcov_mode have type `enum kcov_mode']
    [akpm@linux-foundation.org: unbreak allmodconfig]
    [akpm@linux-foundation.org: follow x86 Makefile layout standards]
    Signed-off-by: Dmitry Vyukov
    Reviewed-by: Kees Cook
    Cc: syzkaller
    Cc: Vegard Nossum
    Cc: Catalin Marinas
    Cc: Tavis Ormandy
    Cc: Will Deacon
    Cc: Quentin Casasnovas
    Cc: Kostya Serebryany
    Cc: Eric Dumazet
    Cc: Alexander Potapenko
    Cc: Kees Cook
    Cc: Bjorn Helgaas
    Cc: Sasha Levin
    Cc: David Drysdale
    Cc: Ard Biesheuvel
    Cc: Andrey Ryabinin
    Cc: Kirill A. Shutemov
    Cc: Jiri Slaby
    Cc: Ingo Molnar
    Cc: Thomas Gleixner
    Cc: "H. Peter Anvin"
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Dmitry Vyukov
     

17 Mar, 2016

1 commit

  • Pull power management and ACPI updates from Rafael Wysocki:
    "This time the majority of changes go into cpufreq and they are
    significant.

    First off, the way CPU frequency updates are triggered is different
    now. Instead of having to set up and manage a deferrable timer for
    each CPU in the system to evaluate and possibly change its frequency
    periodically, cpufreq governors set up callbacks to be invoked by the
    scheduler on a regular basis (basically on utilization updates). The
    "old" governors, "ondemand" and "conservative", still do all of their
    work in process context (although that is triggered by the scheduler
    now), but intel_pstate does it all in the callback invoked by the
    scheduler with no need for any additional asynchronous processing.

    Of course, this eliminates the overhead related to the management of
    all those timers, but also it allows the cpufreq governor code to be
    simplified quite a bit. On top of that, the common code and data
    structures used by the "ondemand" and "conservative" governors are
    cleaned up and made more straightforward and some long-standing and
    quite annoying problems are addressed. In particular, the handling of
    governor sysfs attributes is modified and the related locking becomes
    more fine grained which allows some concurrency problems to be avoided
    (particularly deadlocks with the core cpufreq code).

    In principle, the new mechanism for triggering frequency updates
    allows utilization information to be passed from the scheduler to
    cpufreq. Although the current code doesn't make use of it, in the
    works is a new cpufreq governor that will make decisions based on the
    scheduler's utilization data. That should allow the scheduler and
    cpufreq to work more closely together in the long run.

    In addition to the core and governor changes, cpufreq drivers are
    updated too. Fixes and optimizations go into intel_pstate, the
    cpufreq-dt driver is updated on top of some modification in the
    Operating Performance Points (OPP) framework and there are fixes and
    other updates in the powernv cpufreq driver.

    Apart from the cpufreq updates there is some new ACPICA material,
    including a fix for a problem introduced by previous ACPICA updates,
    and some less significant changes in the ACPI code, like CPPC code
    optimizations, ACPI processor driver cleanups and support for loading
    ACPI tables from initrd.

    Also updated are the generic power domains framework, the Intel RAPL
    power capping driver and the turbostat utility and we have a bunch of
    traditional assorted fixes and cleanups.

    Specifics:

    - Redesign of cpufreq governors and the intel_pstate driver to make
    them use callbacks invoked by the scheduler to trigger CPU
    frequency evaluation instead of using per-CPU deferrable timers for
    that purpose (Rafael Wysocki).

    - Reorganization and cleanup of cpufreq governor code to make it more
    straightforward and fix some concurrency problems in it (Rafael
    Wysocki, Viresh Kumar).

    - Cleanup and improvements of locking in the cpufreq core (Viresh
    Kumar).

    - Assorted cleanups in the cpufreq core (Rafael Wysocki, Viresh
    Kumar, Eric Biggers).

    - intel_pstate driver updates including fixes, optimizations and a
    modification to make it enable enable hardware-coordinated P-state
    selection (HWP) by default if supported by the processor (Philippe
    Longepe, Srinivas Pandruvada, Rafael Wysocki, Viresh Kumar, Felipe
    Franciosi).

    - Operating Performance Points (OPP) framework updates to improve its
    handling of voltage regulators and device clocks and updates of the
    cpufreq-dt driver on top of that (Viresh Kumar, Jon Hunter).

    - Updates of the powernv cpufreq driver to fix initialization and
    cleanup problems in it and correct its worker thread handling with
    respect to CPU offline, new powernv_throttle tracepoint (Shilpasri
    Bhat).

    - ACPI cpufreq driver optimization and cleanup (Rafael Wysocki).

    - ACPICA updates including one fix for a regression introduced by
    previos changes in the ACPICA code (Bob Moore, Lv Zheng, David Box,
    Colin Ian King).

    - Support for installing ACPI tables from initrd (Lv Zheng).

    - Optimizations of the ACPI CPPC code (Prashanth Prakash, Ashwin
    Chaugule).

    - Support for _HID(ACPI0010) devices (ACPI processor containers) and
    ACPI processor driver cleanups (Sudeep Holla).

    - Support for ACPI-based enumeration of the AMBA bus (Graeme Gregory,
    Aleksey Makarov).

    - Modification of the ACPI PCI IRQ management code to make it treat
    255 in the Interrupt Line register as "not connected" on x86 (as
    per the specification) and avoid attempts to use that value as a
    valid interrupt vector (Chen Fan).

    - ACPI APEI fixes related to resource leaks (Josh Hunt).

    - Removal of modularity from a few ACPI drivers (BGRT, GHES,
    intel_pmic_crc) that cannot be built as modules in practice (Paul
    Gortmaker).

    - PNP framework update to make it treat ACPI_RESOURCE_TYPE_SERIAL_BUS
    as a valid resource type (Harb Abdulhamid).

    - New device ID (future AMD I2C controller) in the ACPI driver for
    AMD SoCs (APD) and in the designware I2C driver (Xiangliang Yu).

    - Assorted ACPI cleanups (Colin Ian King, Kaiyen Chang, Oleg Drokin).

    - cpuidle menu governor optimization to avoid a square root
    computation in it (Rasmus Villemoes).

    - Fix for potential use-after-free in the generic device properties
    framework (Heikki Krogerus).

    - Updates of the generic power domains (genpd) framework including
    support for multiple power states of a domain, fixes and debugfs
    output improvements (Axel Haslam, Jon Hunter, Laurent Pinchart,
    Geert Uytterhoeven).

    - Intel RAPL power capping driver updates to reduce IPI overhead in
    it (Jacob Pan).

    - System suspend/hibernation code cleanups (Eric Biggers, Saurabh
    Sengar).

    - Year 2038 fix for the process freezer (Abhilash Jindal).

    - turbostat utility updates including new features (decoding of more
    registers and CPUID fields, sub-second intervals support, GFX MHz
    and RC6 printout, --out command line option), fixes (syscall jitter
    detection and workaround, reductioin of the number of syscalls
    made, fixes related to Xeon x200 processors, compiler warning
    fixes) and cleanups (Len Brown, Hubert Chrzaniuk, Chen Yu)"

    * tag 'pm+acpi-4.6-rc1-1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm: (182 commits)
    tools/power turbostat: bugfix: TDP MSRs print bits fixing
    tools/power turbostat: correct output for MSR_NHM_SNB_PKG_CST_CFG_CTL dump
    tools/power turbostat: call __cpuid() instead of __get_cpuid()
    tools/power turbostat: indicate SMX and SGX support
    tools/power turbostat: detect and work around syscall jitter
    tools/power turbostat: show GFX%rc6
    tools/power turbostat: show GFXMHz
    tools/power turbostat: show IRQs per CPU
    tools/power turbostat: make fewer systems calls
    tools/power turbostat: fix compiler warnings
    tools/power turbostat: add --out option for saving output in a file
    tools/power turbostat: re-name "%Busy" field to "Busy%"
    tools/power turbostat: Intel Xeon x200: fix turbo-ratio decoding
    tools/power turbostat: Intel Xeon x200: fix erroneous bclk value
    tools/power turbostat: allow sub-sec intervals
    ACPI / APEI: ERST: Fixed leaked resources in erst_init
    ACPI / APEI: Fix leaked resources
    intel_pstate: Do not skip samples partially
    intel_pstate: Remove freq calculation from intel_pstate_calc_busy()
    intel_pstate: Move intel_pstate_calc_busy() into get_target_pstate_use_performance()
    ...

    Linus Torvalds
     

11 Mar, 2016

1 commit

  • Create cpufreq.c under kernel/sched/ and move the cpufreq code
    related to the scheduler to that file and to sched.h.

    Redefine cpufreq_update_util() as a static inline function to avoid
    function calls at its call sites in the scheduler code (as suggested
    by Peter Zijlstra).

    Also move the definition of struct update_util_data and declaration
    of cpufreq_set_update_util_data() from include/linux/cpufreq.h to
    include/linux/sched.h.

    Signed-off-by: Rafael J. Wysocki
    Acked-by: Peter Zijlstra (Intel)

    Rafael J. Wysocki
     

25 Feb, 2016

1 commit

  • The existing wait queue support has support for custom wake up call
    backs, wake flags, wake key (passed to call back) and exclusive
    flags that allow wakers to be tagged as exclusive, for limiting
    the number of wakers.

    In a lot of cases, none of these features are used, and hence we
    can benefit from a slimmed down version that lowers memory overhead
    and reduces runtime overhead.

    The concept originated from -rt, where waitqueues are a constant
    source of trouble, as we can't convert the head lock to a raw
    spinlock due to fancy and long lasting callbacks.

    With the removal of custom callbacks, we can use a raw lock for
    queue list manipulations, hence allowing the simple wait support
    to be used in -rt.

    [Patch is from PeterZ which is based on Thomas version. Commit message is
    written by Paul G.
    Daniel: - Fixed some compile issues
    - Added non-lazy implementation of swake_up_locked as suggested
    by Boqun Feng.]

    Originally-by: Thomas Gleixner
    Signed-off-by: Daniel Wagner
    Acked-by: Peter Zijlstra (Intel)
    Cc: linux-rt-users@vger.kernel.org
    Cc: Boqun Feng
    Cc: Marcelo Tosatti
    Cc: Steven Rostedt
    Cc: Paul Gortmaker
    Cc: Paolo Bonzini
    Cc: "Paul E. McKenney"
    Link: http://lkml.kernel.org/r/1455871601-27484-2-git-send-email-wagi@monom.org
    Signed-off-by: Thomas Gleixner

    Peter Zijlstra (Intel)
     

08 May, 2015

1 commit

  • I could not find the loadavg code.. turns out it was hidden in a file
    called proc.c. It further got mingled up with the cruft per rq load
    indexes (which we really want to get rid of).

    Move the per rq load indexes into the fair.c load-balance code (that's
    the only thing that uses them) and rename proc.c to loadavg.c so we
    can find it again.

    Signed-off-by: Peter Zijlstra (Intel)
    Cc: Borislav Petkov
    Cc: H. Peter Anvin
    Cc: Paul Gortmaker
    Cc: Thomas Gleixner
    [ Did minor cleanups to the code. ]
    Signed-off-by: Ingo Molnar

    Peter Zijlstra
     

29 Jan, 2015

1 commit

  • If the kernel is compiled with function tracer support the -pg compile option
    is passed to gcc to generate extra code into the prologue of each function.

    This patch replaces the "open-coded" -pg compile flag with a CC_FLAGS_FTRACE
    makefile variable which architectures can override if a different option
    should be used for code generation.

    Acked-by: Steven Rostedt
    Signed-off-by: Heiko Carstens
    Signed-off-by: Martin Schwidefsky

    Heiko Carstens
     

11 Feb, 2014

1 commit

  • Integration of cpuidle with the scheduler requires that the idle loop be
    closely integrated with the scheduler proper. Moving cpu/idle.c into the
    sched directory will allow for a smoother integration, and eliminate a
    subdirectory which contained only one source file.

    Signed-off-by: Nicolas Pitre
    Signed-off-by: Peter Zijlstra
    Cc: Linus Torvalds
    Cc: Andrew Morton
    Cc: Thomas Gleixner
    Link: http://lkml.kernel.org/r/alpine.LFD.2.11.1401301102210.1652@knanqh.ubzr
    Signed-off-by: Ingo Molnar

    Nicolas Pitre
     

13 Jan, 2014

2 commits

  • Data from tests confirmed that the original active load balancing
    logic didn't scale neither in the number of CPU nor in the number of
    tasks (as sched_rt does).

    Here we provide a global data structure to keep track of deadlines
    of the running tasks in the system. The structure is composed by
    a bitmask showing the free CPUs and a max-heap, needed when the system
    is heavily loaded.

    The implementation and concurrent access scheme are kept simple by
    design. However, our measurements show that we can compete with sched_rt
    on large multi-CPUs machines [1].

    Only the push path is addressed, the extension to use this structure
    also for pull decisions is straightforward. However, we are currently
    evaluating different (in order to decrease/avoid contention) data
    structures to solve possibly both problems. We are also going to re-run
    tests considering recent changes inside cpupri [2].

    [1] http://retis.sssup.it/~jlelli/papers/Ospert11Lelli.pdf
    [2] http://www.spinics.net/lists/linux-rt-users/msg06778.html

    Signed-off-by: Juri Lelli
    Signed-off-by: Peter Zijlstra
    Link: http://lkml.kernel.org/r/1383831828-15501-14-git-send-email-juri.lelli@gmail.com
    Signed-off-by: Ingo Molnar

    Juri Lelli
     
  • Introduces the data structures, constants and symbols needed for
    SCHED_DEADLINE implementation.

    Core data structure of SCHED_DEADLINE are defined, along with their
    initializers. Hooks for checking if a task belong to the new policy
    are also added where they are needed.

    Adds a scheduling class, in sched/dl.c and a new policy called
    SCHED_DEADLINE. It is an implementation of the Earliest Deadline
    First (EDF) scheduling algorithm, augmented with a mechanism (called
    Constant Bandwidth Server, CBS) that makes it possible to isolate
    the behaviour of tasks between each other.

    The typical -deadline task will be made up of a computation phase
    (instance) which is activated on a periodic or sporadic fashion. The
    expected (maximum) duration of such computation is called the task's
    runtime; the time interval by which each instance need to be completed
    is called the task's relative deadline. The task's absolute deadline
    is dynamically calculated as the time instant a task (better, an
    instance) activates plus the relative deadline.

    The EDF algorithms selects the task with the smallest absolute
    deadline as the one to be executed first, while the CBS ensures each
    task to run for at most its runtime every (relative) deadline
    length time interval, avoiding any interference between different
    tasks (bandwidth isolation).
    Thanks to this feature, also tasks that do not strictly comply with
    the computational model sketched above can effectively use the new
    policy.

    To summarize, this patch:
    - introduces the data structures, constants and symbols needed;
    - implements the core logic of the scheduling algorithm in the new
    scheduling class file;
    - provides all the glue code between the new scheduling class and
    the core scheduler and refines the interactions between sched/dl
    and the other existing scheduling classes.

    Signed-off-by: Dario Faggioli
    Signed-off-by: Michael Trimarchi
    Signed-off-by: Fabio Checconi
    Signed-off-by: Juri Lelli
    Signed-off-by: Peter Zijlstra
    Link: http://lkml.kernel.org/r/1383831828-15501-4-git-send-email-juri.lelli@gmail.com
    Signed-off-by: Ingo Molnar

    Dario Faggioli
     

06 Nov, 2013

2 commits


07 May, 2013

1 commit

  • This large chunk of load calculation code can be easily divorced
    from the main core.c scheduler file, with only a couple
    prototypes and externs added to a kernel/sched header.

    Some recent commits expanded the code and the documentation of
    it, making it large enough to warrant separation. For example,
    see:

    556061b, "sched/nohz: Fix rq->cpu_load[] calculations"
    5aaa0b7, "sched/nohz: Fix rq->cpu_load calculations some more"
    5167e8d, "sched/nohz: Rewrite and fix load-avg computation -- again"

    More importantly, it helps reduce the size of the main
    sched/core.c by yet another significant amount (~600 lines).

    Signed-off-by: Paul Gortmaker
    Acked-by: Peter Zijlstra
    Cc: Frederic Weisbecker
    Link: http://lkml.kernel.org/r/1366398650-31599-2-git-send-email-paul.gortmaker@windriver.com
    Signed-off-by: Ingo Molnar

    Paul Gortmaker
     

10 Apr, 2013

1 commit


20 Aug, 2012

1 commit

  • Extract cputime code from the giant sched/core.c and
    put it in its own file. This make it easier to deal with
    this particular area and de-bloat a bit more core.c

    Signed-off-by: Frederic Weisbecker
    Acked-by: Martin Schwidefsky
    Cc: Tony Luck
    Cc: Fenghua Yu
    Cc: Benjamin Herrenschmidt
    Cc: Paul Mackerras
    Cc: Heiko Carstens
    Cc: Ingo Molnar
    Cc: Thomas Gleixner
    Cc: Peter Zijlstra

    Frederic Weisbecker
     

05 May, 2012

1 commit

  • All archs define init_task in the same way (except ia64, but there is
    no particular reason why ia64 cannot use the common version). Create a
    generic instance so all archs can be converted over.

    The config switch is temporary and will be removed when all archs are
    converted over.

    Signed-off-by: Thomas Gleixner
    Cc: Benjamin Herrenschmidt
    Cc: Chen Liqin
    Cc: Chris Metcalf
    Cc: Chris Zankel
    Cc: David Howells
    Cc: David S. Miller
    Cc: Geert Uytterhoeven
    Cc: Guan Xuetao
    Cc: Haavard Skinnemoen
    Cc: Hirokazu Takata
    Cc: James E.J. Bottomley
    Cc: Jesper Nilsson
    Cc: Jonas Bonn
    Cc: Mark Salter
    Cc: Martin Schwidefsky
    Cc: Heiko Carstens
    Cc: Matt Turner
    Cc: Michal Simek
    Cc: Mike Frysinger
    Cc: Paul Mundt
    Cc: Ralf Baechle
    Cc: Richard Kuo
    Cc: Richard Weinberger
    Cc: Russell King
    Cc: Yoshinori Sato
    Link: http://lkml.kernel.org/r/20120503085034.092585287@linutronix.de

    Thomas Gleixner
     

17 Nov, 2011

1 commit