GitLab Commit is coming up on August 3-4. Learn how to innovate together using GitLab, the DevOps platform. Register for free:

  1. 31 Jul, 2021 1 commit
    • Charan Teja Reddy's avatar
      mm: compaction: support triggering of proactive compaction by user · d0331863
      Charan Teja Reddy authored
      The proactive compaction[1] gets triggered for every 500msec and run
      compaction on the node for COMPACTION_HPAGE_ORDER (usually order-9)
      pages based on the value set to sysctl.compaction_proactiveness.
      Triggering the compaction for every 500msec in search of
      COMPACTION_HPAGE_ORDER pages is not needed for all applications,
      especially on the embedded system usecases which may have few MB's of
      RAM. Enabling the proactive compaction in its state will endup in
      running almost always on such systems.
      Other side, proactive compaction can still be very much useful for
      getting a set of higher order pages in some controllable
      manner(controlled by using the sysctl.compaction_proactiveness). So, on
      systems where enabling the proactive compaction always may proove not
      required, can trigger the same from user space on write to its sysctl
      interface. As an example, say app launcher decide to launch the memory
      heavy application which can be launched fast if it gets more higher
      order pages thus launcher can prepare the system in advance by
      triggering the proactive compaction from userspace.
      This triggering of proactive compaction is done on a write to
      sysctl.compaction_proactiveness by user.
      Acked-by: default avatarVlastimil Babka <>
      Signed-off-by: default avatarCharan Teja Reddy <>
  2. 26 Jul, 2021 1 commit
  3. 10 Jul, 2021 1 commit
  4. 28 Jun, 2021 1 commit
  5. 27 Jun, 2021 2 commits
    • Linus Torvalds's avatar
      Linux 5.13 · 62fb9874
      Linus Torvalds authored
    • Linus Torvalds's avatar
      Revert "signal: Allow tasks to cache one sigqueue struct" · b4b27b9e
      Linus Torvalds authored
      This reverts commits 4bad58eb (and
      399f8dd9, which tried to fix it).
      I do not believe these are correct, and I'm about to release 5.13, so am
      reverting them out of an abundance of caution.
      The locking is odd, and appears broken.
      On the allocation side (in __sigqueue_alloc()), the locking is somewhat
      straightforward: it depends on sighand->siglock.  Since one caller
      doesn't hold that lock, it further then tests 'sigqueue_flags' to avoid
      the case with no locks held.
      On the freeing side (in sigqueue_cache_or_free()), there is no locking
      at all, and the logic instead depends on 'current' being a single
      thread, and not able to race with itself.
      To make things more exciting, there's also the data race between freeing
      a signal and allocating one, which is handled by using WRITE_ONCE() and
      READ_ONCE(), and being mutually exclusive wrt the initial state (ie
      freeing will only free if the ol...
  6. 26 Jun, 2021 2 commits
  7. 25 Jun, 2021 32 commits