<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/lib/sort.c, branch v3.4.110</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v3.4.110</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v3.4.110'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2009-01-08T16:31:14Z</updated>
<entry>
<title>generic swap(): lib/sort.c: rename swap to swap_func</title>
<updated>2009-01-08T16:31:14Z</updated>
<author>
<name>Wu Fengguang</name>
<email>fengguang.wu@intel.com</email>
</author>
<published>2009-01-08T02:09:11Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=b53907c0100a353a7ac53bed260e735e5ccbbbcc'/>
<id>urn:sha1:b53907c0100a353a7ac53bed260e735e5ccbbbcc</id>
<content type='text'>
This is to avoid name clashes for the introduction of a global swap()
macro.

Signed-off-by: Wu Fengguang &lt;fengguang.wu@intel.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>lib/sort.c optimization</title>
<updated>2007-10-17T15:42:52Z</updated>
<author>
<name>Subbaiah Venkata</name>
<email>kvsnaidu@sapnaidu.net</email>
</author>
<published>2007-10-17T06:27:06Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=995e4286a047b32aebf8ce540908edb7fbd93f76'/>
<id>urn:sha1:995e4286a047b32aebf8ce540908edb7fbd93f76</id>
<content type='text'>
Hello, I fixed and tested a small bug in lib/sort.c file, heap sort
function.

The fix avoids unnecessary swap of contents when i is 0 (saves few loads
and stores), which happens every time sort function is called.  I felt the
fix is worth bringing it to your attention given the importance and
frequent use of the sort function.

Acked-by: Matt Mackall &lt;mpm@selenic.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>[PATCH] Numerous fixes to kernel-doc info in source files.</title>
<updated>2007-02-11T18:51:32Z</updated>
<author>
<name>Robert P. J. Day</name>
<email>rpjday@mindspring.com</email>
</author>
<published>2007-02-10T09:45:59Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=72fd4a35a824331d7a0f4168d7576502d95d34b3'/>
<id>urn:sha1:72fd4a35a824331d7a0f4168d7576502d95d34b3</id>
<content type='text'>
A variety of (mostly) innocuous fixes to the embedded kernel-doc content in
source files, including:

  * make multi-line initial descriptions single line
  * denote some function names, constants and structs as such
  * change erroneous opening '/*' to '/**' in a few places
  * reword some text for clarity

Signed-off-by: Robert P. J. Day &lt;rpjday@mindspring.com&gt;
Cc: "Randy.Dunlap" &lt;rdunlap@xenotime.net&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>[PATCH] low performance of lib/sort.c</title>
<updated>2006-10-03T15:03:41Z</updated>
<author>
<name>keios</name>
<email>keios.cn@gmail.com</email>
</author>
<published>2006-10-03T08:13:49Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=d3717bdf8f08a0e1039158c8bab2c24d20f492b6'/>
<id>urn:sha1:d3717bdf8f08a0e1039158c8bab2c24d20f492b6</id>
<content type='text'>
It is a non-standard heap-sort algorithm implementation because the index
of child node is wrong .  The sort function still outputs right result, but
the performance is O( n * ( log(n) + 1 ) ) , about 10% ~ 20% worse than
standard algorithm.

Signed-off-by: keios &lt;keios.cn@gmail.com&gt;
Acked-by: Matt Mackall &lt;mpm@selenic.com&gt;
Acked-by: Zou Nan hai &lt;nanhai.zou@intel.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@osdl.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@osdl.org&gt;
</content>
</entry>
<entry>
<title>[PATCH] fix missing includes</title>
<updated>2005-10-31T01:37:32Z</updated>
<author>
<name>Tim Schmielau</name>
<email>tim@physik3.uni-rostock.de</email>
</author>
<published>2005-10-30T23:03:48Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=4e57b6817880946a3a78d5d8cad1ace363f7e449'/>
<id>urn:sha1:4e57b6817880946a3a78d5d8cad1ace363f7e449</id>
<content type='text'>
I recently picked up my older work to remove unnecessary #includes of
sched.h, starting from a patch by Dave Jones to not include sched.h
from module.h. This reduces the number of indirect includes of sched.h
by ~300. Another ~400 pointless direct includes can be removed after
this disentangling (patch to follow later).
However, quite a few indirect includes need to be fixed up for this.

In order to feed the patches through -mm with as little disturbance as
possible, I've split out the fixes I accumulated up to now (complete for
i386 and x86_64, more archs to follow later) and post them before the real
patch.  This way this large part of the patch is kept simple with only
adding #includes, and all hunks are independent of each other.  So if any
hunk rejects or gets in the way of other patches, just drop it.  My scripts
will pick it up again in the next round.

Signed-off-by: Tim Schmielau &lt;tim@physik3.uni-rostock.de&gt;
Signed-off-by: Andrew Morton &lt;akpm@osdl.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@osdl.org&gt;
</content>
</entry>
<entry>
<title>[PATCH] lib/sort.c: small cleanups</title>
<updated>2005-09-10T17:06:31Z</updated>
<author>
<name>Adrian Bunk</name>
<email>bunk@stusta.de</email>
</author>
<published>2005-09-10T07:26:59Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=ecec4cb7a9df5f61fe00710d2f2c69ce9a3b1d40'/>
<id>urn:sha1:ecec4cb7a9df5f61fe00710d2f2c69ce9a3b1d40</id>
<content type='text'>
This patch contains the following small cleanups:
- make two needlessly global functions static
- every file should #include the header files containing the prototypes
  of it's global functions

Signed-off-by: Adrian Bunk &lt;bunk@stusta.de&gt;
Signed-off-by: Andrew Morton &lt;akpm@osdl.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@osdl.org&gt;
</content>
</entry>
<entry>
<title>[PATCH] fix lib/sort regression test</title>
<updated>2005-05-05T23:36:50Z</updated>
<author>
<name>Domen Puncer</name>
<email>domen@coderock.org</email>
</author>
<published>2005-05-05T23:16:19Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=d28c2bc8d192f606a4eb831978722107b20a9405'/>
<id>urn:sha1:d28c2bc8d192f606a4eb831978722107b20a9405</id>
<content type='text'>
The regression test in lib/sort.c is currently worthless because the array
that is generated for sorting will be all zeros.  This patch fixes things
so that the array that is generated will contain unsorted integers (that
are not all identical) as was probably intended.

Signed-off-by Daniel Dickman &lt;didickman@yahoo.com&gt;
Signed-off-by: Domen Puncer &lt;domen@coderock.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@osdl.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@osdl.org&gt;
</content>
</entry>
<entry>
<title>[PATCH] lib/sort: Heapsort implementation of sort()</title>
<updated>2005-03-08T02:04:55Z</updated>
<author>
<name>Matt Mackall</name>
<email>mpm@selenic.com</email>
</author>
<published>2005-03-08T02:04:55Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=8c63b6d337534a6b5fb111dc27d0850f535118c0'/>
<id>urn:sha1:8c63b6d337534a6b5fb111dc27d0850f535118c0</id>
<content type='text'>
This patch adds a generic array sorting library routine. This is meant
to replace qsort, which has two problem areas for kernel use.

The first issue is quadratic worst-case performance. While quicksort
worst-case datasets are rarely encountered in normal scenarios, it is
in fact quite easy to construct worst cases for almost all quicksort
algorithms given source or access to an element comparison callback.
This could allow attackers to cause sorts that would otherwise take
less than a millisecond to take seconds and sorts that should take
less than a second to take weeks or months. Fixing this problem
requires randomizing pivot selection with a secure random number
generator, which is rather expensive.

The second is that quicksort's recursion tracking requires either
nontrivial amounts of stack space or dynamic memory allocation and out
of memory error handling.

By comparison, heapsort has both O(n log n) average and worst-case
performance and practically no extra storage requirements. This
version runs within 70-90% of the average performance of optimized
quicksort so it should be an acceptable replacement wherever quicksort
would be used in the kernel.

Note that this function has an extra parameter for passing in an
optimized swapping function. This is worth 10% or more over the
typical byte-by-byte exchange functions.

Benchmarks:

qsort:     glibc variant            1189 bytes (+ 256/1024 stack)
qsort_3f:  my simplified variant     459 bytes (+ 256/1024 stack)
heapsort:  the version below         346 bytes
shellsort: an optimized shellsort    196 bytes

                         P4 1.8GHz        Opteron 1.4GHz (32-bit)
size   algorithm      cycles relative        cycles relative
100:
           qsort:      38682 100.00%	      27631 100.00%
        qsort_3f:      36277 106.63%	      22406 123.32%
        heapsort:      43574  88.77%	      30301  91.19%
       shellsort:      39087  98.97%	      25139 109.91%
200:									  
           qsort:      86468 100.00%	      61148 100.00%
        qsort_3f:      78918 109.57%	      48959 124.90%
        heapsort:      98040  88.20%	      68235  89.61%
       shellsort:      95688  90.36%	      62279  98.18%
400:									  
           qsort:     187720 100.00%	     131313 100.00%
        qsort_3f:     174905 107.33%	     107954 121.64%
        heapsort:     223896  83.84%	     154241  85.13%
       shellsort:     223037  84.17%	     148990  88.14%
800:									  
           qsort:     407060 100.00%	     287460 100.00%
        qsort_3f:     385106 105.70%	     239131 120.21%
        heapsort:     484662  83.99%	     340099  84.52%
       shellsort:     537110  75.79%	     354755  81.03%
1600:									    
           qsort:     879596 100.00%	     621331 100.00%
        qsort_3f:     861568 102.09%	     522013 119.03%
        heapsort:    1079750  81.46%	     746677  83.21%
       shellsort:    1234243  71.27%	     820782  75.70%
3200:									    
           qsort:    1903902 100.00%	    1342126 100.00%
        qsort_3f:    1908816  99.74%	    1131496 118.62%
        heapsort:    2515493  75.69%	    1630333  82.32%
       shellsort:    2985339  63.78%	    1964794  68.31%
6400:									    
           qsort:    4046370 100.00%	    2909215 100.00%
        qsort_3f:    4164468  97.16%	    2468393 117.86%
        heapsort:    5150659  78.56%	    3533585  82.33%
       shellsort:    6650225  60.85%	    4429849  65.67%
12800:									   
           qsort:    8729730 100.00%	    6185097 100.00%
        qsort_3f:    8776885  99.46%	    5288826 116.95%
        heapsort:   11064224  78.90%	    7603061  81.35%
       shellsort:   15487905  56.36%	   10305163  60.02%
25600:									   
           qsort:   18357770 100.00%	   13172205 100.00%
        qsort_3f:   18687842  98.23%	   11337115 116.19%
        heapsort:   24121241  76.11%	   16612122  79.29%
       shellsort:   35552814  51.64%	   24106987  54.64%
51200:									   
           qsort:   38658883 100.00%	   28008505 100.00%
        qsort_3f:   39498463  97.87%	   24339675 115.07%
        heapsort:   50553552  76.47%	   37013828  75.67%
       shellsort:   82602416  46.80%	   56201889  49.84%
102400:									  
           qsort:   81197794 100.00%	   58918933 100.00%
        qsort_3f:   84257930  96.37%	   51986219 113.34%
        heapsort:  110540577  73.46%	   81419675  72.36%
       shellsort:  191303132  42.44%	  129786472  45.40%
From: Zou Nan hai &lt;nanhai.zou@intel.com&gt;

The new sort routine only works if there are an even number of entries in
the ia64 exception fix-up tables.  If the number of entries is odd the sort
fails, and then random get_user/put_user calls can fail.

Signed-off-by: Matt Mackall &lt;mpm@selenic.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@osdl.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@osdl.org&gt;
</content>
</entry>
</feed>
