1. 30 Jun, 2006 1 commit
  2. 29 Jun, 2006 1 commit
  3. 28 Jun, 2006 6 commits
  4. 27 Jun, 2006 1 commit
  5. 26 Jun, 2006 6 commits
  6. 25 Jun, 2006 8 commits
  7. 23 Jun, 2006 7 commits
  8. 22 Jun, 2006 1 commit
    • Richard Purdie's avatar
      [PATCH] zlib_inflate: Upgrade library code to a recent version · 4f3865fb
      Richard Purdie authored
      Upgrade the zlib_inflate implementation in the kernel from a patched
      version 1.1.3/4 to a patched 1.2.3.
      
      The code in the kernel is about seven years old and I noticed that the
      external zlib library's inflate performance was significantly faster (~50%)
      than the code in the kernel on ARM (and faster again on x86_32).
      
      For comparison the newer deflate code is 20% slower on ARM and 50% slower
      on x86_32 but gives an approx 1% compression ratio improvement.  I don't
      consider this to be an improvement for kernel use so have no plans to
      change the zlib_deflate code.
      
      Various changes have been made to the zlib code in the kernel, the most
      significant being the extra functions/flush option used by ppp_deflate.
      This update reimplements the features PPP needs to ensure it continues to
      work.
      
      This code has been tested on ARM under both JFFS2 (with zlib compression
      enabled) and ppp_deflate and on x86_32.  JFFS2 sees an approx.  10% real
      world file read speed improvement.
      
      This patch also removes ZLIB_VERSION as it no longer has a correct value.
      We don't need version checks anyway as the kernel's module handling will
      take care of that for us.  This removal is also more in keeping with the
      zlib author's wishes (http://www.zlib.net/zlib_faq.html#faq24) and I've
      added something to the zlib.h header to note its a modified version.
      Signed-off-by: default avatarRichard Purdie <rpurdie@rpsys.net>
      Acked-by: default avatarJoern Engel <joern@wh.fh-wedel.de>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
      4f3865fb
  9. 21 Jun, 2006 2 commits
  10. 05 Jun, 2006 1 commit
  11. 21 May, 2006 1 commit
  12. 12 May, 2006 1 commit
  13. 27 Apr, 2006 2 commits
  14. 21 Apr, 2006 2 commits
    • David Woodhouse's avatar
      [RBTREE] Merge colour and parent fields of struct rb_node. · 55a98102
      David Woodhouse authored
      We only used a single bit for colour information, so having a whole
      machine word of space allocated for it was a bit wasteful. Instead,
      store it in the lowest bit of the 'parent' pointer, since that was
      always going to be aligned anyway.
      Signed-off-by: default avatarDavid Woodhouse <dwmw2@infradead.org>
      55a98102
    • David Woodhouse's avatar
      [RBTREE] Remove dead code in rb_erase() · 1975e593
      David Woodhouse authored
      Observe rb_erase(), when the victim node 'old' has two children so
      neither of the simple cases at the beginning are taken.
      
      Observe that it effectively does an 'rb_next()' operation to find the
      next (by value) node in the tree. That is; we go to the victim's
      right-hand child and then follow left-hand pointers all the way
      down the tree as far as we can until we find the next node 'node'. We
      end up with 'node' being either the same immediate right-hand child of
      'old', or one of its descendants on the far left-hand side.
      
      For a start, we _know_ that 'node' has a parent. We can drop that check.
      
      We also know that if 'node's parent is 'old', then 'node' is the
      right-hand child of its parent. And that if 'node's parent is _not_
      'old', then 'node' is the left-hand child of its parent.
      
      So instead of checking for 'node->rb_parent == old' in one place and
      also checking 'node's heritage separately when we're trying to change
      its link from its parent, we can shuffle things around a bit and do
      it like this...
      Signed-off-by: default avatarDavid Woodhouse <dwmw2@infradead.org>
      1975e593