Announcement

Collapse
No announcement yet.

The ~200 Line Linux Kernel Patch That Does Wonders

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • phoronix
    started a topic The ~200 Line Linux Kernel Patch That Does Wonders

    The ~200 Line Linux Kernel Patch That Does Wonders

    Phoronix: The ~200 Line Linux Kernel Patch That Does Wonders

    In recent weeks and months there has been quite a bit of work towards improving the responsiveness of the Linux desktop with some very significant milestones building up recently and new patches continuing to come. This work is greatly improving the experience of the Linux desktop when the computer is withstanding a great deal of CPU load and memory strain. Fortunately, the exciting improvements are far from over. There is a new patch that has not yet been merged but has undergone a few revisions over the past several weeks and it is quite small -- just over 200 lines of code -- but it does wonders for the Linux desktop.

    http://www.phoronix.com/vr.php?view=15455

  • kernelOfTruth
    replied
    please apply:

    Update9:

    *Hotfix* for zcache:


    2.6.37_plus_v16_zcache_linux-next_fixes.patch (2.85 KB) (multiupload.com)

    2.6.37_plus_v16_zcache_linux-next_fixes.patch (pastebin.com mirror)

    Originally posted by md5sum 2.6.37_plus_v16_zcache_linux-next_fixes.patch
    9fc278096e07c8bde4af7ebb5ee823bb 2.6.37_plus_v16_zcache_linux-next_fixes.patch
    contents:

    * [PATCH] zcache: Fix build error when sysfs is not defined
    * static int cleancache_get_key from linux-next
    * fix for fs/super.c (will be included in next release of zcache) - kudos & thanks to Dan Magenheimer !

    Leave a comment:


  • kernelOfTruth
    replied
    Originally posted by kernelOfTruth View Post
    (re-uploaded & added missing patches to changelog and patch(set))

    Update8:

    Everyone's advised to update to v16 !

    (as always - this is a cumulative update of all patches from the beginning)



    you can try to use btrfs with zcache but most likely a (yet to be fixed) BUG will be triggered: http://forums.gentoo.org/viewtopic-p...9.html#6571799

    upstream has been notified - no solution or patch to fix it has been posted yet

    - more efficiency in CFS (cpu scheduler): removed cruft from HT scheduler
    - more memory efficiency: fixed memory leaks in zcache, filesystem, and "fs: remove 8 bytes of padding from block_device on 64bit builds"
    - latest btrfs from February 15th
    - fixes for ext4 & ability to disable inode_readahead_blks (inode_readahead_blks=0)
    - linux-phc (undervolting of the CPU to prolong battery runtime on note- and netbooks)

    kudos to all devs making this possible !

    linux-phc only seems to support undervolting - no over- or underclocking so far

    so you still need to set those things in your Bios or EFI

    - linux-phc (undervolting of the CPU to prolong battery runtime on note- and netbooks)

    Leave a comment:


  • kernelOfTruth
    replied
    (re-uploaded & added missing patches to changelog and patch(set))

    Update8:

    Everyone's advised to update to v16 !

    (as always - this is a cumulative update of all patches from the beginning)

    changes (for v15 -> v16):

    "25 kztmem" --> "25 zcache"
    2 [PATCH] staging: zcache: fix memory leak
    3 [PATCH] zcache: Fix build error when sysfs is not defined

    27 even more changes ->
    13 fs: remove 8 bytes of padding from block_device on 64bit builds
    14 (V2) Fix prlimit64 for suid_sgid processes

    23 post-2.6.37-fixes -> 4 ext4 -> 12 new_v16
    1 [patch] ext4: off by one check in ext4_groupinfo_create_slab()
    3 [PATCH] jbd2: call __jbd2_log_start_commit with j_state_lock write locked
    4 [PATCH] ext4: allow inode_readahead_blks=0 (linux-2.6.37)

    20 2.6.38_patches -> 7 CFS -> 11 v16_sd_idle and first_idle_cpu
    1 sched-Resolve-sd_idle-and-first_idle_cpu-Catch-22---v1
    2 [PATCH] sched: Wholesale removal of sd_idle logic

    20 2.6.38_patches -> 13_timer ->
    5 (feb6) [GIT\ PULL\]\ timer\ fixes.txt

    20 2.6.38_patches -> 15 x86\ platform ->
    8 [PATCH\]\ x86\:\ Fix\ io_bitmap_ptr\ memory\ leak\ on\ copy_process\(\)

    32 linux-phc_phc-intel
    phc-intel-0.3.2.12.1-2.6.37.patch

    "31 btrfs"
    -> included latest btrfs changes from 2.6.37 to 2.6.38-rc4 (as of February 15th) (commit: c26a920373a983b52223eed5a13b97404d8b4158 (as of February 15th) in http://git.eu.kernel.org/?p=linux/ke....git;a=summary)
    1 btrfs-2.6.38-rc4_feb-15th.patch
    2 [PATCH] fix (latent?) memory corruption in btrfs_encode_fh()
    you can try to use btrfs with zcache but most likely a (yet to be fixed) BUG will be triggered: http://forums.gentoo.org/viewtopic-p...9.html#6571799

    upstream has been notified - no solution or patch to fix it has been posted yet

    - more efficiency in CFS (cpu scheduler): removed cruft from HT scheduler
    - more memory efficiency: fixed memory leaks in zcache, filesystem, and "fs: remove 8 bytes of padding from block_device on 64bit builds"
    - latest btrfs from February 15th
    - fixes for ext4 & ability to disable inode_readahead_blks (inode_readahead_blks=0)
    - linux-phc (over- and underclocking)

    kudos to all devs making this possible !

    Leave a comment:


  • kernelOfTruth
    replied
    Update8:

    Everyone's advised to update to v16 !

    (as always - this is a cumulative update of all patches from the beginning)

    changes (for v15 -> v16):

    "25 kztmem" --> "25 zcache"
    2 [PATCH] staging: zcache: fix memory leak
    3 [PATCH] zcache: Fix build error when sysfs is not defined

    27 even more changes ->
    13 fs: remove 8 bytes of padding from block_device on 64bit builds
    14 (V2) Fix prlimit64 for suid_sgid processes

    20 2.6.38_patches -> 7 CFS -> 11 v16_sd_idle and first_idle_cpu
    1 sched-Resolve-sd_idle-and-first_idle_cpu-Catch-22---v1
    2 [PATCH] sched: Wholesale removal of sd_idle logic

    20 2.6.38_patches -> 13_timer ->
    5 (feb6) [GIT\ PULL\]\ timer\ fixes.txt

    20 2.6.38_patches -> 15 x86\ platform ->
    8 [PATCH\]\ x86\:\ Fix\ io_bitmap_ptr\ memory\ leak\ on\ copy_process\(\)

    "31 btrfs"
    -> included latest btrfs changes from 2.6.37 to 2.6.38-rc4 (as of February 15th) (commit: c26a920373a983b52223eed5a13b97404d8b4158 (as of February 15th) in http://git.eu.kernel.org/?p=linux/ke....git;a=summary)
    1 btrfs-2.6.38-rc4_feb-15th.patch
    2 [PATCH] fix (latent?) memory corruption in btrfs_encode_fh()
    you can try to use btrfs with zcache but most likely a (yet to be fixed) BUG will be triggered: http://forums.gentoo.org/viewtopic-p...9.html#6571799

    upstream has been notified - no solution or patch to fix it has been posted yet

    - more efficiency in CFS (cpu scheduler): removed cruft from HT scheduler
    - more memory efficiency: fixed memory leaks in zcache, filesystem, and "fs: remove 8 bytes of padding from block_device on 64bit builds"
    - latest btrfs from February 15th

    kudos to all devs making this possible !

    Leave a comment:


  • kernelOfTruth
    replied
    those who are using the patchset with the CFS autogroup included & other goodies

    v15 is out !

    2.6.37_plus kernel with coordinate flush, zcache or TOI

    Update5:

    Everyone's advised to update to v15

    v15 includes all changes since v14

    changes (for v14 -> v15):

    20 2.6.38_patches/15 x86 platform ->
    7 [tip:x86_urgent] x86-32: Make sure the stack is set up before we use it

    "25 kztmem" --> rename & bump from V1 to V2 to "25 zcache"
    1 zcache-linux-2.6.37-110205.patch

    (IMPORTANT NOTE: zcache MUST be specified as a kernel boot parameter or
    nothing happens!) And if you love to see tons of detailed statstics
    changing dynamically try running the following bash script in a big window
    with "watch -d":
    http://oss.oracle.com/projects/tmem/...e/zcache-stats

    the "new" zcache by Dan Magenheimer & Nitin Gupta


    27 even more fixes -> 9 uvesafb, vesafb ->
    1 [PATCH 1_3] uvesafb,vesafb: create WC or WB PAT entries
    2 [PATCH 2_3] Add ioremap_cache and ioremap_wc to all architectures
    3 [PATCH 3_3] uvesafb: remove-ifdef-CONFIG_X86-around-ioremap

    Leave a comment:


  • kernelOfTruth
    replied
    Originally posted by roysamuel View Post
    Thanks for that bit of info. You are saying then that, rc3 and rc6 are relatively more stable than rc2, rc1 and rc5, rc4? I'm not sure if I got you correctly. By the way, when would the stable version of 2.6.38 be released?
    nope I'd only say that there are sort of 3 phases:

    1) before rc3: high probability that you might get into data corruption (depending on the new features that got into the kernel release)

    2) before rc3-rc6 should be better but still some issues possible

    3) >rc6 everyone testing please


    stable 2.6.38 ? probably in a month or 1.5 - but mostly "when it's done"

    Leave a comment:


  • roysamuel
    replied
    Originally posted by kernelOfTruth View Post
    watch out for rc-kernels before rc3 and rc6

    there still might be potential bugs leading to data corruption (e.g. the case for <2.6.37-rc6)

    have backups available - just in case ...
    Thanks for that bit of info. You are saying then that, rc3 and rc6 are relatively more stable than rc2, rc1 and rc5, rc4? I'm not sure if I got you correctly. By the way, when would the stable version of 2.6.38 be released?

    Leave a comment:


  • kernelOfTruth
    replied
    Originally posted by roysamuel View Post
    I downloaded the 2.6.38-rc3 kernel source and compiled it with CONFIG_SCHED_AUTOGROUP=y
    Great to see switching between different applications have sped up a lot! yaay
    Thanks to all you who helped.
    watch out for rc-kernels before rc3 and rc6

    there still might be potential bugs leading to data corruption (e.g. the case for <2.6.37-rc6)

    have backups available - just in case ...

    Leave a comment:


  • roysamuel
    replied
    Tried it...Its great!

    I downloaded the 2.6.38-rc3 kernel source and compiled it with CONFIG_SCHED_AUTOGROUP=y
    Great to see switching between different applications have sped up a lot! yaay
    Thanks to all you who helped.

    Leave a comment:

Working...
X