cpufreq: interactive: squash in my optimized interactive governor

Signed-off-by: Blechd0se <alex.christ@hotmail.de>
arm: switch to XZ compression

gzip: File size ~ 4 MB
xz:   File size ~ 2 MB

(This time for real).

Signed-off-by: Blechd0se <alex.christ@hotmail.de>
gitignore: add auto generated files

Signed-off-by: Blechd0se <alex.christ@hotmail.de>
misc: add dynamic writeback interface

Before this patch, the deamon for flushing
dirty pages kicks in every 600 ms. This patch
changes the behaviour a little bit. While suspended
it flushes more pages (every 500 ms) and while the
the device is awake and in use it flushes only every
4 s to gain a little performance boost.

This is fully controllable;

echo 1 > /sys/devices/virtual/misc/writeback/writeback_enabled
(1 = On (default), 0 = off (and behaviour before this
patch).

Signed-off-by: Blechd0se <alex.christ@hotmail.de>
AIO: Don't plug the I/O queue in do_io_submit() Asynchronous I/O late…
…ncy 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: Blechd0se <alex.christ@hotmail.de>
logger: get some ram back

Signed-off-by: Blechd0se <alex.christ@hotmail.de>
vram: reducing vram size (6 -> 4)

Signed-off-by: Blechd0se <alex.christ@hotmail.de>
update defconfig

* Added deadline scheduler and made it default
* enabled kmemleak detector
* some random cleanups

Signed-off-by: Blechd0se <alex.christ@hotmail.de>
deadline: update tunables

Update the deadline tunables to the same we used on 2.6.32.
Also change the behaviour for deadline to react more
like a fifo scheduler.

Signed-off-by: Blechd0se <alex.christ@hotmail.de>
media: video: fix video_dma_unmap needs *dev

Fix up some warnings.

Signed-off-by: Blechd0se <alex.christ@hotmail.de>
display: add basic display control

While i am trying to solve the wakeup delay i noticed
that the panel driver uses different brightness values
for different phones (red / green lense).
With a small display control driver those values
can be easily exposed to userspace.
Green ones used to have 0x09, those colors looked a bit
washed out.

echo xx > /sys/class/misc/display_control/display_brightness_value

Where xx can be (theoretically) a value between 0 and 255.
0  will set the screen to almost 0,
9  will set the screen to some kind of blue-washed colors,
31 will set the screen to more warmer colors (new default).

I also changed the sequence in mapphone_panel_disable_local().
This solves the "distorted" screen for me and also the wakeup
delay *seems* to be solved.

Signed-off-by: Blechd0se <alex.christ@hotmail.de>
fs: ext3/4 enable xattr

For better compatibility for 4.4, like
we in our 2.6.32 branch.

Signed-off-by: Blechd0se <alex.christ@hotmail.de>
ext3: fix start and len arguments handling in ext3_trim_fs()

The overflow might happen when passing blocknr into
ext3_get_group_no_and_offset(), because it expects type ext3_fsblk_t
which might be smaller than uint64_t. This will most likely happen when
calling FITRIM with the default argument len = ULLONG_MAX.

Fix this by using "end" variable instead of "start+len" as it is easier
to get right and specifically check that the end is not beyond the end
of the file system, so we are sure that the result of
get_group_no_and_offset() will not overflow. Otherwise truncate it to
the size of the file system.

Signed-off-by: Lukas Czerner <lczerner@redhat.com>
Cc: Jan Kara <jack@suse.cz>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Blechd0se <alex.christ@hotmail.de>

Conflicts:
	fs/ext3/balloc.c
ext3: Avoid underflow of in ext3_trim_fs()

Currently if len argument in ext3_trim_fs() is smaller than one block,
the 'end' variable underflow. Avoid that by returning EINVAL if len is
smaller than file system block.

Also remove useless unlikely().

Signed-off-by: Lukas Czerner <lczerner@redhat.com>
Signed-off-by: Jan Kara <jack@suse.cz>
ext4: fix trim length underflow with small trim length

In 0f0a25b, we adjust 'len' with s_first_data_block - start, but
it could underflow in case blocksize=1K, fstrim_range.len=512 and
fstrim_range.start = 0. In this case, when we run the code:
len -= first_data_blk - start; len will be underflow to -1ULL.
In the end, although we are safe that last_group check later will limit
the trim to the whole volume, but that isn't what the user really want.

So this patch fix it. It also adds the check for 'start' like ext3 so that
we can break immediately if the start is invalid.

Cc: Lukas Czerner <lczerner@redhat.com>
Signed-off-by: Tao Ma <boyu.mt@taobao.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
ext4: speed up group trim with the right free block count

When we trim some free blocks in a group of ext4, we need to
calculate the free blocks properly and check whether there are
enough freed blocks left for us to trim. Current solution will
only calculate free spaces if they are large for a trim which
isn't appropriate.

Let us see a small example:
a group has 1.5M free which are 300k, 300k, 300k, 300k, 300k.
And minblocks is 1M.  With current solution, we have to iterate
the whole group since these 300k will never be subtracted from
1.5M.  But actually we should exit after we find the first 2
free spaces since the left 3 chunks only sum up to 900K if we
subtract the first 600K although they can't be trimed.

Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Signed-off-by: Tao Ma <boyu.mt@taobao.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
ext4: Add new ext4 trim tracepoints

Add ext4_trim_extent and ext4_trim_all_free.

Reviewed-by: Lukas Czerner <lczerner@redhat.com>
Signed-off-by: Tao Ma <boyu.mt@taobao.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Blechd0se <alex.christ@hotmail.de>

Conflicts:
	include/trace/events/ext4.h
ext4: Speed up FITRIM by recording flags in ext4_group_info

In ext4, when FITRIM is called every time, we iterate all the
groups and do trim one by one. It is a bit time wasting if the
group has been trimmed and there is no change since the last
trim.

So this patch adds a new flag in ext4_group_info->bb_state to
indicate that the group has been trimmed, and it will be cleared
if some blocks is freed(in release_blocks_on_commit). Another
trim_minlen is added in ext4_sb_info to record the last minlen
we use to trim the volume, so that if the caller provide a small
one, we will go on the trim regardless of the bb_state.

A simple test with my intel x25m ssd:
df -h shows:
/dev/sdb1              40G   21G   17G  56% /mnt/ext4
Block size:               4096

run the FITRIM with the following parameter:
range.start = 0;
range.len = UINT64_MAX;
range.minlen = 1048576;

without the patch:
[root@boyu-tm linux-2.6]# time ./ftrim /mnt/ext4/a
real	0m5.505s
user	0m0.000s
sys	0m1.224s
[root@boyu-tm linux-2.6]# time ./ftrim /mnt/ext4/a
real	0m5.359s
user	0m0.000s
sys	0m1.178s
[root@boyu-tm linux-2.6]# time ./ftrim /mnt/ext4/a
real	0m5.228s
user	0m0.000s
sys	0m1.151s

with the patch:
[root@boyu-tm linux-2.6]# time ./ftrim /mnt/ext4/a
real	0m5.625s
user	0m0.000s
sys	0m1.269s
[root@boyu-tm linux-2.6]# time ./ftrim /mnt/ext4/a
real	0m0.002s
user	0m0.000s
sys	0m0.001s
[root@boyu-tm linux-2.6]# time ./ftrim /mnt/ext4/a
real	0m0.002s
user	0m0.000s
sys	0m0.001s

A big improvement for the 2nd and 3rd run.

Even after I delete some big image files, it is still much
faster than iterating the whole disk.

[root@boyu-tm test]# time ./ftrim /mnt/ext4/a
real	0m1.217s
user	0m0.000s
sys	0m0.196s

Cc: Lukas Czerner <lczerner@redhat.com>
Reviewed-by: Andreas Dilger <adilger.kernel@dilger.ca>
Signed-off-by: Tao Ma <boyu.mt@taobao.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
ext4: Change the wrong param comment for ext4_trim_all_free

at ext4_trim_all_free() comment, there is no longer an @e4b parameter,
instead it is @group.

Reported-by: Andreas Dilger <adilger@dilger.ca>
Signed-off-by: Tao Ma <boyu.mt@taobao.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
ext4: fix start and len arguments handling in ext4_trim_fs()

The overflow can happen when we are calling get_group_no_and_offset()
which stores the group number in the ext4_grpblk_t type which is
actually int. However when the blocknr is big enough the group number
might be bigger than ext4_grpblk_t resulting in overflow. This will
most likely happen with FITRIM default argument len = ULLONG_MAX.

Fix this by using "end" variable instead of "start+len" as it is easier
to get right and specifically check that the end is not beyond the end
of the file system, so we are sure that the result of
get_group_no_and_offset() will not overflow. Otherwise truncate it to
the size of the file system.

Signed-off-by: Lukas Czerner <lczerner@redhat.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Blechd0se <alex.christ@hotmail.de>

Conflicts:
	fs/ext4/mballoc.c