The Ultra Kernel Samepage Merging feature
Ultra KSM. Copyright (C) 2011-2012 Nai Xia

This is an improvement upon KSM. Some basic data structures and routines
are borrowed from ksm.c .

Its new features:
1. Full system scan:
     It automatically scans all user processes' anonymous VMAs. Kernel-user
     interaction to submit a memory area to KSM is no longer needed.

2. Rich area detection:
     It automatically detects rich areas containing abundant duplicated
     pages based. Rich areas are given a full scan speed. Poor areas are
     sampled at a reasonable speed with very low CPU consumption.

3. Ultra Per-page scan speed improvement:
     A new hash algorithm is proposed. As a result, on a machine with
     Core(TM)2 Quad Q9300 CPU in 32-bit mode and 800MHZ DDR2 main memory, it
     can scan memory areas that does not contain duplicated pages at speed of
     627MB/sec ~ 2445MB/sec and can merge duplicated areas at speed of
     477MB/sec ~ 923MB/sec.

4. Thrashing area avoidance:
     Thrashing area(an VMA that has frequent Ksm page break-out) can be
     filtered out. My benchmark shows it's more efficient than KSM's per-page
     hash value based volatile page detection.

5. Misc changes upon KSM:
    It has a fully x86-opitmized memcmp dedicated for 4-byte-aligned page
       comparison. It's much faster than default C version on x86.
    rmap_item now has an structpage member to loosely cache a
       address-->page mapping, which reduces too much time-costly
       follow_page().
    The VMA creation/exit procedures are hooked to let the Ultra KSM know.
    try_to_merge_two_pages() now can revert a pte if it fails. No break_
       ksm is needed for this case.

6. Full Zero Page consideration(contributed by Figo Zhang)
   Now uksmd consider full zero pages as special pages and merge them to an
   special unswappable uksm zero page.

Signed-off-by: GuneetAtwal <harjinder767@gmail.com>
af_unix: speedup /proc/net/unix
/proc/net/unix has quadratic behavior, and can hold unix_table_lock for
a while if high number of unix sockets are alive. (90 ms for 200k
sockets...)

We already have a hash table, so its quite easy to use it.

Problem is unbound sockets are still hashed in a single hash slot
(unix_socket_table[UNIX_HASH_TABLE])

This patch also spreads unbound sockets to 256 hash slots, to speedup
both /proc/net/unix and unix_diag.

Time to read /proc/net/unix with 200k unix sockets :
(time dd if=/proc/net/unix of=/dev/null bs=4k)

before : 520 secs
after : 2 secs

Signed-off-by: Eric Dumazet <edumazet@google.com>
Cc: Steven Whitehouse <swhiteho@redhat.com>
Cc: Pavel Emelyanov <xemul@parallels.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
net: loopback: set default mtu to 64K

loopback current mtu of 16436 bytes allows no more than 3 MSS TCP
segments per frame, or 48 Kbytes. Changing mtu to 64K allows TCP
stack to build large frames and significantly reduces stack overhead.

Performance boost on bulk TCP transferts can be up to 30 %, partly
because we now have one ACK message for two 64KB segments, and a lower
probability of hitting /proc/sys/net/ipv4/tcp_reordering default limit.

Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: franciscofranco <franciscofranco.1990@gmail.com>
 cfs: tweaks for responsiveness
kernel:sched: LOAD_FREQ (4*HZ+61) avoids loadavg Moire

LOAD_FREQ is (5*HZ+1) to avoid high load average when idle:
http://kerneltrap.org/mailarchive/linux-kernel/2007/10/3/328568

I suggest (4*HZ+61) for a better distribution.

With some seconds based load (like SSL heartbeats)
and LOAD_FREQ at (5*HZ+1) I see Moire patterns like inverse sawtooth,
since 2 or 3 probes hit the jobs (load increases quickly),
followed by several probes missing it.

A 4.61 sec interval gives optimal distribution over when within a
second a probe is taken, as .61 is close to golden ratio phi 1.618...
(test in http://ripke.com/goldenratio.c).

12*4.61 = 55.32 secs is still close to a minute,
and 13*4.61=59.93 is even closer than the current 12*5.01=60.12
(with exponents EXP_x adjusted to a ratio of 13 instead of 12).