cpufreq: cultivation: bring in initial release
-based off of caf 4.4 commits
-uses per-cpu timers
-use display_state for screen off timer
with option to set different timer rate when screen off
-improrted fastlane with threshold from blu_active
Signed-off-by: mydongistiny <jaysonedson@gmail.com>
cpufreq: cultivation: update with a few new tuneables
added in:
go_lowspeed_load
validate above_hispeed_delay
check hispeed_freq is within the policy limits
powersave_bias
version bump to 1.5
Signed-off-by: mydongistiny <jaysonedson@gmail.com>
cpufreq_notify_utilization - notify CPU userspace about CPU utilization change
This function is called everytime the CPU load is evaluated by the
ondemand governor. It notifies userspace of cpu load changes via sysfs.
Some modules can benefit from getting additional information cpufreq
governors use to make frequency switch decisions.
This change lays down a basic framework that the governors can use
to report additional information (Eg: CPU's load) information to
the clients that subscribe to cpufreq govinfo notifier chain.
Change-Id: I511b4bdb7d12394a31ce5352ae47553861e49303
Signed-off-by: Rohit Gupta <rohgup@codeaurora.org>
[imaund@codeaurora.org: resolved context conflicts]
Signed-off-by: Ian Maund <imaund@codeaurora.org>
sync_file_range(2) is documented to issue writeback only for pages that
are not currently being written. After all the system call has been
created for userspace to be able to issue background writeout and so
waiting for in-flight IO is undesirable there. However commit
ee53a89 ("mm: do_sync_mapping_range integrity fix") switched
do_sync_mapping_range() and thus sync_file_range() to issue writeback in
WB_SYNC_ALL mode since do_sync_mapping_range() was used by other code
relying on WB_SYNC_ALL semantics.
These days do_sync_mapping_range() went away and we can switch
sync_file_range(2) back to issuing WB_SYNC_NONE writeback. That should
help PostgreSQL avoid large latency spikes when flushing data in the
background.
Andres measured a 20% increase in transactions per second on an SSD
disk.
Signed-off-by: Jan Kara <jack@suse.com>
Reported-by: Andres Freund <andres@anarazel.de>
Tested-By: Andres Freund <andres@anarazel.de>
Cc: Al Viro <viro@ZenIV.linux.org.uk>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Dave Jones reported RCU stalls, overly long hrtimer interrupts, and
amazingly long NMI handlers from a trinity-induced workload involving
lots of concurrent sync() calls (https://lkml.org/lkml/2013/7/23/369).
There are any number of things that one might do to make sync() behave
better under high levels of contention, but it is also the case that
multiple concurrent sync() system calls can be satisfied by a single
sys_sync() invocation.
Given that this situation is reminiscent of rcu_barrier(), this commit
applies the rcu_barrier() approach to sys_sync(). This approach uses
a global mutex and a sequence counter. The mutex is held across the
sync() operation, which eliminates contention between concurrent sync()
operations. The counter is incremented at the beginning and end of
each sync() operation, so that it is odd while a sync() operation is in
progress and even otherwise, just like sequence locks.
The code that used to be in sys_sync() is now in do_sync(), and
sys_sync()
now handles the concurrency. The sys_sync() function first takes a
snapshot of the counter, then acquires the mutex, and then takes another
snapshot of the counter. If the values of the two snapshots indicate
that
a full do_sync() executed during the mutex acquisition, the sys_sync()
function releases the mutex and returns ("Our work is done!").
Otherwise,
sys_sync() increments the counter, invokes do_sync(), and increments
the counter again.
This approach allows a single call to do_sync() to satisfy an
arbitrarily
large number of sync() system calls, which should eliminate issues due
to large numbers of concurrent invocations of the sync() system call.
Changes since v1 (https://lkml.org/lkml/2013/7/24/683):
o Add a pair of memory barriers to keep the increments from
bleeding into the do_sync() code. (The failure probability
is insanely low, but when you have several hundred million
devices running Linux, you can expect several hundred instances
of one-in-a-million failures.)
o Actually CC some people who have experience in this area.
Reported-by: Dave Jones <davej@redhat.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Jan Kara <jack@suse.cz>
Cc: Curt Wohlgemuth <curtw@google.com>
Cc: Jens Axboe <jaxboe@fusionio.com>
Cc: linux-fsdevel@vger.kernel.org
Signed-off-by: Paul Reioux <reioux@gmail.com>
Enabling software CRCs on the data blocks can be a significant (30%) performance cost, and for other reasons may not always be desired. CRC is a mechanism aiming to prevent data corruption when enabled (reduce the performance around 30%). So if you disable it (improve the performance) but your data can be corrupted. Use it at your risk.
* ***** SysFs interface :
*
* /sys/module/mmc_core/parameters/crc
*
* Enable / Disable CRC
*
* echo N > /sys/module/mmc_core/parameters/crc (Disabled) or
* echo 0 > /sys/module/mmc_core/parameters/crc (Disabled)
*
* echo Y > /sys/module/mmc_core/parameters/crc (Enabled) or
* echo 1 > /sys/module/mmc_core/parameters/crc (Enabled)
*
*
* ***** (default = Enabled)
Signed-off-by: Pafcholini <pafcholini@gmail.com>
Signed-off-by: Pafcholini <nadyaivanova14@gmail.com>
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: ahmedradaideh <ahmed.radaideh@gmail.com>
Sleeping for an entire tick adds unnecessary latency to
hotplugging a cpu (cpu_up).
Change-Id: Iab323a79f4048bc9101ecfd368e0f275827ed4ab
Signed-off-by: Steve Muckle <smuckle@codeaurora.org>
[rameezmustafa@codeaurora.org]: Port to msm-3.18]
Signed-off-by: Syed Rameez Mustafa <rameezmustafa@codeaurora.org>
add_random was implemented for spinning hard disks. It only slows SSDs down. Read here http://wiki.samat.org/SSD for more info.
Signed-off-by: Chester Kener <Cl3Kener@gmail.com>
Signed-off-by: engstk <eng.stk@sapo.pt>
This commit allows to enable/disable via config @jesec Fake Enforcing Status patch or @jcadduono SELinux Force Enforcing/Permissive patch
Signed-off-by: BlackMesa123 <brother12@hotmail.it>
proc: update or inserted cmdline-flags required for proper SafetyNet-support
proc: cmdline: set warranty bit-flags to 0
proc: cmdline: fix invalid handling of value-changing
Change-Id: Idec862bcf9125a79ac9505a938495f114636b4fc
