[Kernel] - 3.1.10 - JB - 1.4GHZ - Galaxy Tab 10.1 (11/19/12)
- Thread starter pershoot
- Start date
using file explorer, re-install superSU (delete from system/app folder), and re-install superSU, and give the right permission superSU.apk, reboot your tablet. once reboots, open superSU so it can update binaries, first run it may ask permissions for other apps, let's grant the permissions.
it no longer prompts permission, then again reboot your tablet. and see iif you still have issue.
---------- Post added at 01:12 PM ---------- Previous post was at 01:10 PM ----------
very good:good:
11/19 has been merged in to mainline. will be in next nightly.
The 11-19 kernel with the 11-19 CM10 running great on LTE version; keep up the great work.
nice...so I don't need to worry to flash this kernel after the nightly ROM flash going forward, right?
Yester nightly has the old kernel
Sent from my GT-P7510 using xda app-developers app
Sent from my GT-P7510 using xda app-developers app
11/21 doesn't have pershoot's kernel yet?
We have to flash 11/19 kernel till next nightly after 11/21? Confirmed above...
Also what's the default number of background processes? You can set none, default, or 1-4 but what's the default or is it dependent on something?
Also I saw someone say they were changing I/O scheduler from cfq to noop... is this recommended with interactive governor? Why would u do this?
---------- Post added at 10:57 AM ---------- Previous post was at 10:41 AM ----------
http://forum.xda-developers.com/showthread.php?t=1179809
Chamonix's app helps figure out what is happening :^}
We have to flash 11/19 kernel till next nightly after 11/21? Confirmed above...
Also what's the default number of background processes? You can set none, default, or 1-4 but what's the default or is it dependent on something?
Also I saw someone say they were changing I/O scheduler from cfq to noop... is this recommended with interactive governor? Why would u do this?
---------- Post added at 10:57 AM ---------- Previous post was at 10:41 AM ----------
Better Battery Stats
http://forum.xda-developers.com/showthread.php?t=1179809
Chamonix's app helps figure out what is happening :^}
Last edited:
That was me. I've been using pershoot's ROM/kernel since the beginning. In the early stages, he suggested using interactive because of it being developed. I wish I had the thread this was said in. Anyhow, I always decided to go with interactive because of that, testing, research, and what works best on my Tab (every device plays differently). I did some extensive research on I/O schedulers found here and around the web. I found that SIO (which isn't offered in this kernel) and noop do very well. Now I know that CFQ is set by default, but I prefer noop. I'm always open to different opinions, so if anyone sees something I don't see...please let me know.
Nice thing about cm10...
noop
Inserts all the incoming I/O requests to a First In First Out queue and implements request merging. Best used with storage devices that does not depend on mechanical movement to access data (yes, like our flash drives). Advantage here is that flash drives does not require reordering of multiple I/O requests unlike in normal hard drives.
Advantages:
Serves I/O requests with least number of cpu cycles. (Battery friendly?)
Best for flash drives since there is no seeking penalty.
Good throughput on db systems.
Disadvantages:
Reduction in number of cpu cycles used is proportional to drop in performance.
Deadline
Goal is to minimize I/O latency or starvation of a request. The same is achieved by round robin policy to be fair among multiple I/O requests. Five queues are aggressively used to reorder incoming requests.
Advantages:
Nearly a real time scheduler.
Excels in reducing latency of any given single I/O.
Best scheduler for database access and queries.
Bandwidth requirement of a process - what percentage of CPU it needs, is easily calculated.
Like noop, a good scheduler for solid state/flash drives.
Disadvantages:
When system is overloaded, set of processes that may miss deadline is largely unpredictable.
Reduction in number of cpu cycles used is proportional to drop in performance.
CFQ
Completely Fair Queuing scheduler maintains a scalable per-process I/O queue and attempts to distribute the available I/O bandwidth equally among all I/O requests. Each per-process queue contains synchronous requests from processes. Time slice allocated for each queue depends on the priority of the 'parent' process. V2 of CFQ has some fixes which solves process' i/o starvation and some small backward seeks in the hope of improving responsiveness.
Advantages:
Considered to deliver a balanced i/o performance.
Easiest to tune.
Excels on multiprocessor systems.
Best database system performance after deadline.
Disadvantages:
Some users report media scanning takes longest to complete using CFQ. This could be because of the property that since the bandwidth is equally distributed to all i/o operations during boot-up, media scanning is not given any special priority.
Jitter (worst-case-delay) exhibited can sometimes be high, because of the number of tasks competing for the disk.
BFQ
Instead of time slices allocation by CFQ, BFQ assigns budgets. Disk is granted to an active process until it's budget (number of sectors) expires. BFQ assigns high budgets to non-read tasks. Budget assigned to a process varies over time as a function of it's behavior.
Advantages:
Believed to be very good for usb data transfer rate.
Believed to be the best scheduler for HD video recording and video streaming. (because of less jitter as compared to CFQ and others)
Considered an accurate i/o scheduler.
Achieves about 30% more throughput than CFQ on most workloads.
Disadvantages:
Not the best scheduler for benchmarking.
Higher budget assigned to a process can affect interactivity and increased latency.
So, as you can see, setting may help depending on workload. (Like playing or streaming video)
Note on governors: Interactive (default) and best to use at this point for everyday use except benchmarking where performance would be in order:
Can be considered a faster ondemand. So more snappier, less battery. Interactive is designed for latency-sensitive, interactive workloads. Instead of sampling at every interval like ondemand, it determines how to scale up when CPU comes out of idle. The governor has the following advantages: 1) More consistent ramping, because existing governors do their CPU load sampling in a workqueue context, but interactive governor does this in a timer context, which gives more consistent CPU load sampling. 2) Higher priority for CPU frequency increase, thus giving the remaining tasks the CPU performance benefit, unlike existing governors which schedule ramp-up work to occur after your performance starved tasks have completed. Interactive It's an intelligent Ondemand because of stability optimizations. Why??
Sampling the CPU load every X ms (like Ondemand) can lead to under-powering the CPU for X ms, leading to dropped frames, stuttering UI, etc. Instead of sampling the CPU at a specified rate, the interactive governor will check whether to scale the CPU frequency up soon after coming out of idle. When the CPU comes out of idle, a timer is configured to fire within 1-2 ticks. If the CPU is very busy between exiting idle and when the timer fires, then we assume the CPU is underpowered and ramp to max frequency. On top of this pershoot recommends this and has focused development on interactive governor... so just use it unless there's a reason not to and you know what you're doing...i.e. don't set it to performance and then complain in forums about battery life. :^}
Where we used to have to set some things with additional tools/apps or in init scripts some thing are configurable in settings under performance. Governor settings are interactive, performance, conservative, ondemand, and userspace. We used to mostly use ondemand per pershoots recommendation... but that is no longer the case. As already stated above Interactive is the way to go now due to development focused on it by pershoot mainly. The I/O scheduler options are noop, deadline, cfq (default), and bfq:would be nice if you post a print screen how you all set up
noop
Inserts all the incoming I/O requests to a First In First Out queue and implements request merging. Best used with storage devices that does not depend on mechanical movement to access data (yes, like our flash drives). Advantage here is that flash drives does not require reordering of multiple I/O requests unlike in normal hard drives.
Advantages:
Serves I/O requests with least number of cpu cycles. (Battery friendly?)
Best for flash drives since there is no seeking penalty.
Good throughput on db systems.
Disadvantages:
Reduction in number of cpu cycles used is proportional to drop in performance.
Deadline
Goal is to minimize I/O latency or starvation of a request. The same is achieved by round robin policy to be fair among multiple I/O requests. Five queues are aggressively used to reorder incoming requests.
Advantages:
Nearly a real time scheduler.
Excels in reducing latency of any given single I/O.
Best scheduler for database access and queries.
Bandwidth requirement of a process - what percentage of CPU it needs, is easily calculated.
Like noop, a good scheduler for solid state/flash drives.
Disadvantages:
When system is overloaded, set of processes that may miss deadline is largely unpredictable.
Reduction in number of cpu cycles used is proportional to drop in performance.
CFQ
Completely Fair Queuing scheduler maintains a scalable per-process I/O queue and attempts to distribute the available I/O bandwidth equally among all I/O requests. Each per-process queue contains synchronous requests from processes. Time slice allocated for each queue depends on the priority of the 'parent' process. V2 of CFQ has some fixes which solves process' i/o starvation and some small backward seeks in the hope of improving responsiveness.
Advantages:
Considered to deliver a balanced i/o performance.
Easiest to tune.
Excels on multiprocessor systems.
Best database system performance after deadline.
Disadvantages:
Some users report media scanning takes longest to complete using CFQ. This could be because of the property that since the bandwidth is equally distributed to all i/o operations during boot-up, media scanning is not given any special priority.
Jitter (worst-case-delay) exhibited can sometimes be high, because of the number of tasks competing for the disk.
BFQ
Instead of time slices allocation by CFQ, BFQ assigns budgets. Disk is granted to an active process until it's budget (number of sectors) expires. BFQ assigns high budgets to non-read tasks. Budget assigned to a process varies over time as a function of it's behavior.
Advantages:
Believed to be very good for usb data transfer rate.
Believed to be the best scheduler for HD video recording and video streaming. (because of less jitter as compared to CFQ and others)
Considered an accurate i/o scheduler.
Achieves about 30% more throughput than CFQ on most workloads.
Disadvantages:
Not the best scheduler for benchmarking.
Higher budget assigned to a process can affect interactivity and increased latency.
So, as you can see, setting may help depending on workload. (Like playing or streaming video)
Note on governors: Interactive (default) and best to use at this point for everyday use except benchmarking where performance would be in order:
Can be considered a faster ondemand. So more snappier, less battery. Interactive is designed for latency-sensitive, interactive workloads. Instead of sampling at every interval like ondemand, it determines how to scale up when CPU comes out of idle. The governor has the following advantages: 1) More consistent ramping, because existing governors do their CPU load sampling in a workqueue context, but interactive governor does this in a timer context, which gives more consistent CPU load sampling. 2) Higher priority for CPU frequency increase, thus giving the remaining tasks the CPU performance benefit, unlike existing governors which schedule ramp-up work to occur after your performance starved tasks have completed. Interactive It's an intelligent Ondemand because of stability optimizations. Why??
Sampling the CPU load every X ms (like Ondemand) can lead to under-powering the CPU for X ms, leading to dropped frames, stuttering UI, etc. Instead of sampling the CPU at a specified rate, the interactive governor will check whether to scale the CPU frequency up soon after coming out of idle. When the CPU comes out of idle, a timer is configured to fire within 1-2 ticks. If the CPU is very busy between exiting idle and when the timer fires, then we assume the CPU is underpowered and ramp to max frequency. On top of this pershoot recommends this and has focused development on interactive governor... so just use it unless there's a reason not to and you know what you're doing...i.e. don't set it to performance and then complain in forums about battery life. :^}
Last edited:
Similar threads
Top Liked Posts
-
There are no posts matching your filters.
-
226
New posts
-
-
-
-
[HELP THREAD] Ask ANY Question. Noob Friendly.- Latest: Luka.loves.samsung
-