block: Add support for reinsert a dispatched req

Ported to linux 3.0

Change-Id: Ib76b90d7926983f3ae4b1b9e4e6e9d313a71481e
Signed-off-by: zwliew <zhaoweiliew@gmail.com>
block/blk-core: Add supportfor urgent request handling

This patch add support in block & elevator layers for handling
urgent requests. The decision if a request is urgent or not is taken
by the scheduler. Urgent request notification is passed to the underlying
block device driver (eMMC for example). Block device driver may decide to
interrupt the currently running low priority request to serve the new
urgent request. By doing so READ latency is greatly reduced in read&write
collision scenarios.

Note that if the current scheduler doesn't implement the urgent request
mechanism, this code path is never activated.

Ported to linux 3.0
Signed-off-by: zwliew <zhaoweiliew@gmail.com>

Change-Id: I5df5c269eda40692da1eb5e495edf97c4810c9e7
AIO: Don't plug the I/O queue in do_io_submit() Asynchronous I/O latency to a solid-state disk greatly increased between the 2.6.32 and 3.0 kernels. By removing the plug from do_io_submit(), we observed a 34% improvement in the I/O latency.

Unfortunately, at this level, we don't know if the request is to
a rotating disk or not.

Change-Id: I7101df956473ed9fd5dcff18e473dd93b688a5c1
Signed-off-by: Dave Kleikamp <dave.kleikamp@oracle.com>
Cc: linux-aio@kvack.org
Cc: Chris Mason <chris.mason@oracle.com>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Jeff Moyer <jmoyer@redhat.com>
Signed-off-by: zwliew <zhaoweiliew@gmail.com>

Conflicts:
	fs/aio.c

Signed-off-by: zwliew <zhaoweiliew@gmail.com>
ARM: vfp: use -mfloat-abi=soft to build vfp

Distros are starting to ship with toolchains defaulting to
hardfloat. Using such a compiler to build the kernel fails
in the VFP directory with

arch/arm/vfp/entry.S:1:0: sorry, unimplemented: -mfloat-abi=hard and VFP

Adding -mfloat-abi=soft to the gcc command line fixes this.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: zwliew <zhaoweiliew@gmail.com>
SELinux: include definition of new capabilities

The kernel has added CAP_WAKE_ALARM and CAP_EPOLLWAKEUP.  We need to
define these in SELinux so they can be mediated by policy.

Change-Id: I8a3e0db15ec5f4eb05d455a57e8446a8c2b484c2
Signed-off-by: Eric Paris <eparis@redhat.com>
Signed-off-by: James Morris <james.l.morris@oracle.com>
[sds: rename epollwakeup to block_suspend to match upstream merge]
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>

Signed-off-by: zwliew <zhaoweiliew@gmail.com>
[PATCH] SELinux: reduce overhead of mls_level_isvalid()
 function call

Date	Wed, 10 Apr 2013 14:26:22 -0400

While running the high_systime workload of the AIM7 benchmark on
a 2-socket 12-core Westmere x86-64 machine running 3.8.2 kernel,
it was found that a pretty sizable amount of time was spent in the
SELinux code. Below was the perf trace of the "perf record -a -s"
of a test run at 1500 users:

  3.96%            ls  [kernel.kallsyms]     [k] ebitmap_get_bit
  1.44%            ls  [kernel.kallsyms]     [k] mls_level_isvalid
  1.33%            ls  [kernel.kallsyms]     [k] find_next_bit

The ebitmap_get_bit() was the hottest function in the perf-report
output.  Both the ebitmap_get_bit() and find_next_bit() functions
were, in fact, called by mls_level_isvalid(). As a result, the
mls_level_isvalid() call consumed 6.73% of the total CPU time of all
the 24 virtual CPUs which is quite a lot.

Looking at the mls_level_isvalid() function, it is checking to see
if all the bits set in one of the ebitmap structure are also set in
another one as well as the highest set bit is no bigger than the one
specified by the given policydb data structure. It is doing it in
a bit-by-bit manner. So if the ebitmap structure has many bits set,
the iteration loop will be done many times.

The current code can be rewritten to use a similar algorithm as the
ebitmap_contains() function with an additional check for the highest
set bit. With that change, the perf trace showed that the used CPU
time drop down to just 0.09% of the total which is about 100X less
than before.

  0.04%            ls  [kernel.kallsyms]     [k] ebitmap_get_bit
  0.04%            ls  [kernel.kallsyms]     [k] mls_level_isvalid
  0.01%            ls  [kernel.kallsyms]     [k] find_next_bit

Actually, the remaining ebitmap_get_bit() and find_next_bit() function
calls are made by other kernel routines as the new mls_level_isvalid()
function will not call them anymore.

This patch also improves the high_systime AIM7 benchmark result,
though the improvement is not as impressive as is suggested by the
reduction in CPU time. The table below shows the performance change
on the 2-socket x86-64 system mentioned above.

+--------------+---------------+----------------+-----------------+
|   Workload   | mean % change | mean % change  | mean % change   |
|              | 10-100 users  | 200-1000 users | 1100-2000 users |
+--------------+---------------+----------------+-----------------+
| high_systime |     +0.2%     |     +1.1%      |     +2.4%       |
+--------------+---------------+----------------+-----------------+
Signed-off-by: Waiman Long <Waiman.Long@hp.com>

Change-Id: Icd41b0c1b37157d89715910416c05b3f48ed158a
Signed-off-by: Paul Reioux <reioux@gmail.com>
Signed-off-by: zwliew <zhaoweiliew@gmail.com>
ARM: 7415/1: vfp: Convert printk's to pr_*'s

This is mainly to get rid of the "vfp_pm_suspend: saving vfp state"
message flooding the kernel message ring by default.

Change-Id: I44212829cd9eac163cb7e30e043797e6c7c82870
Signed-off-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: zwliew <zhaoweiliew@gmail.com>
sched: Set power savings to POWERSAVINGS_BALANCE_WAKEUP

Ported to linux 3.0

Change-Id: I83b8bd2185815d4d00365ed67bde0c085aa10ac1
Signed-off-by: zwliew <zhaoweiliew@gmail.com>
Speed up console framebuffer imageblit function

Especially on platforms with a slower CPU but a relatively high
framebuffer fill bandwidth, like current ARM devices, the existing
console monochrome imageblit function used to draw console text is
suboptimal for common pixel depths such as 16bpp and 32bpp. The existing
code is quite general and can deal with several pixel depths. By creating
special case functions for 16bpp and 32bpp, by far the most common pixel
formats used on modern systems, a significant speed-up is attained
which can be readily felt on ARM-based devices like the Raspberry Pi
and the Allwinner platform, but should help any platform using the
fb layer.

The special case functions allow constant folding, eliminating a number
of instructions including divide operations, and allow the use of an
unrolled loop, eliminating instructions with a variable shift size,
reducing source memory access instructions, and eliminating excessive
branching. These unrolled loops also allow much better code optimization
by the C compiler. The code that selects which optimized variant is used
is also simplified, eliminating integer divide instructions.

The speed-up, measured by timing 'cat file.txt' in the console, varies
between 40% and 70%, when testing on the Raspberry Pi and Allwinner
ARM-based platforms, depending on font size and the pixel depth, with
the greater benefit for 32bpp.

Change-Id: I559cdd6eed8df649f5b2fda94c94356f70312ab2
Signed-off-by: Harm Hanemaaijer <fgenfb@yahoo.com>
Signed-off-by: zwliew <zhaoweiliew@gmail.com>
Optimize kernel cfbfillrect function

This is a  patch to speed up the kernel
cfbfillrect function used for clearing the screen or filling an area
with a solid color.

The previous implementation was doing reads from the uncached framebuffer,
in certain circumstances, even for simple fills, which for performance
reasons, on most platforms, is ill-advised unless strictly necessary to
conform to the raster operation. In these circumstances, doing 64-bit
access on 64-bit systems does not serve much purpose except for probing
for corner-case bugs and race conditions in the hardware's framebuffer
bus implementation. On all systems, for 16bpp, it is better to take
advantage of write-combining features of the framebuffer and write a
half-word if required for the left and right edges.

Additionally, on most platforms, integer divides are relatively slow so are
best avoided, especially in inner loops.

This patch implements optimizations for 16bpp and 32bpp that avoid
framebuffer read operations during cfbfillrect if the raster-operation
is GXcopy. This applies to both 32-bit (BITS_PER_LONG) and 64-bit
systems (BITS_PER_LONG == 64). Although cfbfillrect is not usually a
bottleneck for the console text framebuffer (because regions filled
usually are aligned to a multiple of 2 or 4 x-coordinate and reads
are avoided), in some use-cases this patch could deliver a significant
speed-up.

Change-Id: Iff22ea9dae6a513d9883aee56d511e109ecbfedd
Signed-off-by: Harm Hanemaaijer <fgenfb@yahoo.com>
Signed-off-by: zwliew <zhaoweiliew@gmail.com>