cpufreq: enable sibling cpu policy sharing
msm: overall_stats: add overall stats for all available cores

this is much more accurate stats tracking than just displaying core 0's
stats from most other kernels

Signed-off-by: faux123 <reioux@gmail.com>

Conflicts:
	drivers/cpufreq/cpufreq_stats.c
msm: overall_stats: make dual/quad core stats configurable via meunconfig

Signed-off-by: faux123 <reioux@gmail.com>
msm: overall_stats: forward port to kernel 3.4+

by replacing deprecated functions with native add/sub for 64bit data types

Signed-off-by: faux123 <reioux@gmail.com>
mutex: Make more scalable by doing less atomic operations

Date	Mon, 15 Apr 2013 10:37:57 -0400

In the __mutex_lock_common() function, an initial entry into
the lock slow path will cause two atomic_xchg instructions to be
issued. Together with the atomic decrement in the fast path, a total
of three atomic read-modify-write instructions will be issued in
rapid succession. This can cause a lot of cache bouncing when many
tasks are trying to acquire the mutex at the same time.

This patch will reduce the number of atomic_xchg instructions used by
checking the counter value first before issuing the instruction. The
atomic_read() function is just a simple memory read. The atomic_xchg()
function, on the other hand, can be up to 2 order of magnitude or even
more in cost when compared with atomic_read(). By using atomic_read()
to check the value first before calling atomic_xchg(), we can avoid a
lot of unnecessary cache coherency traffic. The only downside with this
change is that a task on the slow path will have a tiny bit
less chance of getting the mutex when competing with another task
in the fast path.

The same is true for the atomic_cmpxchg() function in the
mutex-spin-on-owner loop. So an atomic_read() is also performed before
calling atomic_cmpxchg().

The mutex locking and unlocking code for the x86 architecture can allow
any negative number to be used in the mutex count to indicate that some
tasks are waiting for the mutex. I am not so sure if that is the case
for the other architectures. So the default is to avoid atomic_xchg()
if the count has already been set to -1. For x86, the check is modified
to include all negative numbers to cover a larger case.

The following table shows the jobs per minutes (JPM) scalability data
on an 8-node 80-core Westmere box with a 3.7.10 kernel. The numactl
command is used to restrict the running of the high_systime workloads
to 1/2/4/8 nodes with hyperthreading on and off.

+-----------------+-----------+------------+----------+
|  Configuration  | Mean JPM  |  Mean JPM  | % Change |
|		  | w/o patch | with patch |	      |
+-----------------+-----------------------------------+
|		  |      User Range 1100 - 2000	      |
+-----------------+-----------------------------------+
| 8 nodes, HT on  |    36980   |   148590  | +301.8%  |
| 8 nodes, HT off |    42799   |   145011  | +238.8%  |
| 4 nodes, HT on  |    61318   |   118445  |  +51.1%  |
| 4 nodes, HT off |   158481   |   158592  |   +0.1%  |
| 2 nodes, HT on  |   180602   |   173967  |   -3.7%  |
| 2 nodes, HT off |   198409   |   198073  |   -0.2%  |
| 1 node , HT on  |   149042   |   147671  |   -0.9%  |
| 1 node , HT off |   126036   |   126533  |   +0.4%  |
+-----------------+-----------------------------------+
|		  |       User Range 200 - 1000	      |
+-----------------+-----------------------------------+
| 8 nodes, HT on  |   41525    |   122349  | +194.6%  |
| 8 nodes, HT off |   49866    |   124032  | +148.7%  |
| 4 nodes, HT on  |   66409    |   106984  |  +61.1%  |
| 4 nodes, HT off |  119880    |   130508  |   +8.9%  |
| 2 nodes, HT on  |  138003    |   133948  |   -2.9%  |
| 2 nodes, HT off |  132792    |   131997  |   -0.6%  |
| 1 node , HT on  |  116593    |   115859  |   -0.6%  |
| 1 node , HT off |  104499    |   104597  |   +0.1%  |
+-----------------+------------+-----------+----------+
At low user range 10-100, the JPM differences were within +/-1%. So
they are not that interesting.

AIM7 benchmark run has a pretty large run-to-run variance due to random
nature of the subtests executed. So a difference of less than +-5%
may not be really significant.

This patch improves high_systime workload performance at 4 nodes
and up by maintaining transaction rates without significant drop-off
at high node count.  The patch has practically no impact on 1 and 2
nodes system.

The table below shows the percentage time (as reported by perf
record -a -s -g) spent on the __mutex_lock_slowpath() function by
the high_systime workload at 1500 users for 2/4/8-node configurations
with hyperthreading off.

+---------------+-----------------+------------------+---------+
| Configuration | %Time w/o patch | %Time with patch | %Change |
+---------------+-----------------+------------------+---------+
|    8 nodes    |      65.34%     |      0.69%       |  -99%   |
|    4 nodes    |       8.70%	  |      1.02%	     |  -88%   |
|    2 nodes    |       0.41%     |      0.32%       |  -22%   |
+---------------+-----------------+------------------+---------+
It is obvious that the dramatic performance improvement at 8
nodes was due to the drastic cut in the time spent within the
__mutex_lock_slowpath() function.

The table below show the improvements in other AIM7 workloads (at 8
nodes, hyperthreading off).

+--------------+---------------+----------------+-----------------+
|   Workload   | mean % change | mean % change  | mean % change   |
|              | 10-100 users  | 200-1000 users | 1100-2000 users |
+--------------+---------------+----------------+-----------------+
| alltests     |     +0.6%     |   +104.2%      |   +185.9%       |
| five_sec     |     +1.9%     |     +0.9%      |     +0.9%       |
| fserver      |     +1.4%     |     -7.7%      |     +5.1%       |
| new_fserver  |     -0.5%     |     +3.2%      |     +3.1%       |
| shared       |    +13.1%     |   +146.1%      |   +181.5%       |
| short        |     +7.4%     |     +5.0%      |     +4.2%       |
+--------------+---------------+----------------+-----------------+
Signed-off-by: Waiman Long <Waiman.Long@hp.com>
Reviewed-by: Davidlohr Bueso <davidlohr.bueso@hp.com>
mutex: back out architecture specific check for negative mutex count

Date	Mon, 15 Apr 2013 10:37:59 -0400

If it is confirmed that all the supported architectures can allow a
negative mutex count without incorrect behavior, we can then back
out the architecture specific change and allow the mutex count to
go to any negative number. That should further reduce contention for
non-x86 architecture.

If this is not the case, this patch should be dropped.

Signed-off-by: Waiman Long <Waiman.Long@hp.com>
SCHEDULER: Autogroup patch group by current user android UID instead of task ID
jiffies conversions: Use compile time constants when possible

Date	Fri, 04 Jan 2013 13:15:43 -0800

Do the multiplications and divisions at compile time
instead of runtime when the converted value is a constant.

Make the calculation functions static __always_inline to jiffies.h.

Add #defines with __builtin_constant_p to test and use the
static inline or the runtime functions as appropriate.

Prefix the old exported symbols/functions with __

Signed-off-by: Paul Reioux <reioux@gmail.com>
ksm: check and skip page, if it is already scanned

From: Pradeep Sawlani <sawlani@amazon.com>

On system like Android where most of the process are forked
from parent w/o execve, KSM can scan same page multiple times
in one scan cycle. There is no advantage in scanning same page
multiple times for merging. During testing with Android, it was
observed around 60% pages are skipped for each scan cycle.

Change-Id: I0cf01802f0b4d61fcab92558beb9e1c660dc9a77
Link: http://lkml.kernel.org/r/CAMrOTPgBtANS_ryRjan0-dTL97U7eRvtf3dCsss=Kn+Uk89fuA@mail.gmail.com
Signed-off-by: Pradeep Sawlani <sawlani@amazon.com>

Signed-off-by: Paul Reioux <reioux@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: flar2 <asegaert@gmail.com>
msm: mdss: only pass display state to lcd notifier call_chain

* We can pass 'NULL' directly to blocking_notifier_call_chain
* Remove unused struct 'lcd_event'
msm: vidc: fix failure to set LTR with index value

When MARKLTR/USELTR was set with a index value the value never
propagated to firmware resulting in failure to set the property.

Change-Id: I37536e1662c2d1092477fddde6838d4239805ac5
Signed-off-by: Ashray Kulkarni <ashrayk@codeaurora.org>
msm: vidc: Advertise extradata size in queue_setup()

If extradata is enabled, the correct size must be advertised as part of
queue_setup().  Prior to this commit, the output buffer size was taken
to be the extradata size.

In order to make sure that we aren't advertising stale buffer sizes,
query the core for both CAPTURE and OUTPUT planes.

Change-Id: I300e0e1d852caab208fd4cfc6df7cf3152f52431
Signed-off-by: Pushkaraj Patil <ppatil@codeaurora.org>
msm: vidc: disable Hier-P when LTR is enabled

Hier-P and LTR are mutually exclusive in firmware. Disable Hier-P
using HFI_PROPERTY_PARAM_VENC_HIER_P_MAX_NUM_ENH_LAYER
instead of HFI_PROPERTY_CONFIG_VENC_HIER_P_ENH_LAYER.

Change-Id: Ib4eb053a0ccef94c1996392eba19c5b83f7c9971
Signed-off-by: Arun Menon <avmenon@codeaurora.org>
msm: vidc: Add NULL pointer check before deiniting controls

Add NULL pointer check in deinit function, and return -EINVAL
when NULL pointer is found.
Without this change, accidentally, msm_venc_ctrl_deinit() will be called
with a null pointer parameter, which will cause kernel panic.

Change-Id: I80bb6c271dcd3277ddce5332c5f42328ca376128
CRs-Fixed: 652365
Signed-off-by: huiy <huiyQuic@codeaurora.org>
msm: vidc: Bug fix in instance clean-up

When close is called directly without proper state operations,
then driver tries to clean all V4L2 framework memory. When driver
calls queue_release, it tries to call stream_off again. This
causes driver to re-enter the state operations. This change
prevents driver to re-enter the state diagram.

Change-Id: I6df248792fca78fe743bead311fa1cec61a6bb79
Signed-off-by: Praneeth Paladugu <ppaladug@codeaurora.org>
msm: vidc: do not check for session supported in executing state

The v4l2 video driver should check if the video session is supported
only prior to entering the executing state. Once video session is
in executing state, the session should be always honored.

Change-Id: Iaa59089ef05f03bbc821af8c7fd4fbc342067b3a
Signed-off-by: Arun Menon <avmenon@codeaurora.org>
msm-vidc: Modify HFI not to alter VP8 max supported width

Modify HFI not to alter firmware returned max supported width
and height and make generic both for Venus and Q6. Remove
creation of debugfs file for VP8 mode.

Change-Id: I77d9077a79214d90f59eb7314bb66e310b5a418f
Signed-off-by: Manikanta Sivapala <msivap@codeaurora.org>
msm: vidc: avoid setting smoothstreaming for Q6

Smoothstreaming is not a tested functionality on Q6.
This change will return error to all clients trying
to configure Q6 in smoothstreaming mode.

Change-Id: If520d136cd29b3b37759d0fb179538e31b9b71d9
Signed-off-by: Vikash Garodia <vgarodia@codeaurora.org>
Revert "wcnss: handle CBC complete event from firmware"

This reverts commit 7db9a1a9f70a62adf2437484034a7d112c23be1f.
Above commit depends on firmware code changes, As new code
changes that would be introduced removes this dependency,
hence reverting this commit.

Change-Id: I86479d05f98e48949a140e30efae4e311e1cbf00
CRs-Fixed: 744296
Signed-off-by: Anand N Sunkad <asunka@codeaurora.org>