5,600,182 Members 38,733 Now Online
XDA Developers Android and Mobile Development Forum

[KERNEL] [GPL] [GN] franco.Kernel r395

Tip us?
 
malaroth
Old
(Last edited by malaroth; 20th February 2013 at 04:19 PM.)
#39441  
malaroth's Avatar
Senior Member
Thanks Meter 295
Posts: 433
Join Date: Sep 2012
Quote:
Originally Posted by shreddintyres View Post
I intend to start testing your values shortly, i just wanted to add what ive thought up regarding each of the different tunables, (Ive yet to have sufficient free time to really start messing around with each individual tunable and testing the way i would like to as a result of school. but here is atleast some of my theory on how the tunables MIGHT work

Config options
+==============
+1. hp_read_quantum: dispatch quantum for the high priority READ queue
+ (default is 100 requests)
+2. rp_read_quantum: dispatch quantum for the regular priority READ
+ queue (default is 100 requests)
+3. hp_swrite_quantum: dispatch quantum for the high priority
+ Synchronous WRITE queue (default is 2 requests)
+4. rp_swrite_quantum: dispatch quantum for the regular priority
+ Synchronous WRITE queue (default is 1 requests)
+5. rp_write_quantum: dispatch quantum for the regular priority WRITE
+ queue (default is 1 requests)
+6. lp_read_quantum: dispatch quantum for the low priority READ queue
+ (default is 1 requests)
+7. lp_swrite_quantum: dispatch quantum for the low priority Synchronous
+ WRITE queue (default is 1 requests)
+8. read_idle: how long to idle on read queue in Msec (in case idling
+ is enabled on that queue). (default is 5 Msec)
+9. read_idle_freq: frequency of inserting READ requests that will
+ trigger idling. This is the time in Msec between inserting two READ
+ requests. (default is 8 Msec)
+
+Note: Dispatch quantum is number of requests that will be dispatched
+from a certain queue in a dispatch cycle.

my difficulty is understanding lines 1-7 specifically when it references quantum. I've read the note and understand that Dispatch quantum has to do with the number of requests that will be dispatched(discarded?) in a cycle. What i dont understand is quantum referring to something similar to "entropy" that we see mentioned in most kernel documentation?

my understanding that increasing 1-7 will generally lead to lag and greater overhead while dropping it will lead to higher consumption of battery but potentially less overhead increasing overall performance

increasing 8 would lead to lag cuz the cpu would hang in idle longer, definitely increase battery life as power consumption at idle is negligble

increasing 9 would lead to lag and probably worsen battery life to some extent because read actions would take longer to perform and would introduce lag, reducing would lead to generally faster processing of read requests, (presently this is set at 20ms by Default in Franco kernel)

@malaroth i'd appreciate it if you could give me any more insight into what these values mean.

- Cheers
It differs as to which scheduler you're using but they all use algorithms to determine priority. That's where quantum is referenced. It's pretty tough unless you're a math whiz to nail down the perfect numbers but... what I did with my values was to determine if the current row values were too tough on writes or not tough enough on reads. We want our devices snappy and smooth. We don't want to see the device "processing", just know that it's happening in the background. So with that said I decided to lower the regular priority reads just a quarter to not clog the whole io with reads. The lag is coming from writes not getting finished so I increased the synchronous writes (ones that merge together) in the order of priority I felt would be most beneficial without totally eliminating the row function of read over write. In fact increasing read_idle increases io throughput since the idle function is to wait for higher priority data that hadn't been served when the process started but came in between. So instead of sticking it back in the queue it goes ahead and processes it. Increasing read_idle_freq allows more processes to be assigned into that queue. Now the document you got that from states that the default is 8ms... that's not for android. Each device is different. For the Gnex it's 7ms and increases in increments of 8ms. On the n7 default is 10ms with 10 ms increments. We've found that one step above default is the sweet spot. When I first brought these numbers to Franco he was very skeptical. Then he did some hardcore io testing and the numbers just showed better performance.

Edit* this is from Linux-mag on cfq but illustrates how quantum works
"quantum
This parameter controls the number of dispatched requests to the device queue, request-device (i.e. the number of requests that are executed or at least sent for execution). In a queue’s time slice, a request will not be dispatched if the number of requests in the device request-device exceeds this parameter.

Franco r365
JBSourcery 4.5.5
The Following 8 Users Say Thank You to malaroth For This Useful Post: [ Click to Expand ]
 
creeve4
Old
#39442  
Senior Member
Thanks Meter 324
Posts: 1,822
Join Date: Jan 2011
Location: Bountiful
Default Re: [KERNEL][GPL][GN] franco.Kernel r365 -> 4.2.2 | r364 -> 4.2 | r300 -> 4.1

The latest 4.2.2 builds of AOKP will not boot with r365. The propriety binaries/drivers have been merged, but just in case I flashed those listed several pages back. Still won't boot past the Google boot logo.
 
julian.kueh
Old
#39443  
Senior Member
Thanks Meter 7
Posts: 239
Join Date: Feb 2009
Default Re: [KERNEL][GPL][GN] franco.Kernel r365 -> 4.2.2 | r364 -> 4.2 | r300 -> 4.1

I'm running mmuzzy's aosp 4.2.2 on Franco 365. No probs.

Sent from my Galaxy Nexus using xda app-developers app
Galaxy Nexus Dream 4.4
SGTab on ICS
Apple iPad 2
Blackberry Playbook 64Gb OS 2.1 Beta
Blackberry Z10
 
Empty Hand
Old
#39444  
Empty Hand's Avatar
Senior Member
Thanks Meter 46
Posts: 151
Join Date: Jul 2012
Default Re: [KERNEL][GPL][GN] franco.Kernel r365 -> 4.2.2 | r364 -> 4.2 | r300 -> 4.1

Quote:
Originally Posted by creeve4 View Post
The latest 4.2.2 builds of AOKP will not boot with r365. The propriety binaries/drivers have been merged, but just in case I flashed those listed several pages back. Still won't boot past the Google boot logo.
r365 is working fine for me on zaphod's toro build from today (up on Androtransfer). It's the first aokp build that it's worked on for me.

Sent from my Galaxy Nexus using Tapatalk 2
 
creeve4
Old
#39445  
Senior Member
Thanks Meter 324
Posts: 1,822
Join Date: Jan 2011
Location: Bountiful
Quote:
Originally Posted by creeve4 View Post
The latest 4.2.2 builds of AOKP will not boot with r365. The propriety binaries/drivers have been merged, but just in case I flashed those listed several pages back. Still won't boot past the Google boot logo.
Bad kernel download. I re-downloaded from f.KU app and all is good
 
osm0sis
Old
#39446  
osm0sis's Avatar
Recognized Contributor
Thanks Meter 11545
Posts: 6,819
Join Date: Mar 2012
Quote:
Originally Posted by lightingcloud View Post
I don't get it. This is my 900setting

same settings in f.ku

when I reboot, the values in f.ku are all changed to default (except color). why? ?___?
Quote:
Originally Posted by lightingcloud View Post
With or without the comment, it still don't work. None of the command in the file. Should I put them in separate files?

Also I experienced some play store related freezes, and I noticed they happen ONLY when some app is updating/downloading and the screen is about to turn off. If I keep using the device everything is fine.
Did you create the file on PC and copy to phone? My only thought is you have the wrong end-of-line formatting.

Quote:
Originally Posted by malaroth View Post
It differs as to which scheduler you're using but they all use algorithms to determine priority. That's where quantum is referenced. It's pretty tough unless you're a math whiz to nail down the perfect numbers but... what I did with my values was to determine if the current row values were too tough on writes or not tough enough on reads. We want our devices snappy and smooth. We don't want to see the device "processing", just know that it's happening in the background. So with that said I decided to lower the regular priority reads just a quarter to not clog the whole io with reads. The lag is coming from writes not getting finished so I increased the synchronous writes (ones that merge together) in the order of priority I felt would be most beneficial without totally eliminating the row function of read over write. In fact increasing read_idle increases io throughput since the idle function is to wait for higher priority data that hadn't been served when the process started but came in between. So instead of sticking it back in the queue it goes ahead and processes it. Increasing read_idle_freq allows more processes to be assigned into that queue. Now the document you got that from states that the default is 8ms... that's not for android. Each device is different. For the Gnex it's 7ms and increases in increments of 8ms. On the n7 default is 10ms with 10 ms increments. We've found that one step above default is the sweet spot. When I first brought the numbers to Franco he was very skeptical. Then he did some hardcore io testing and the numbers just showed better performance.

Edit* this is from Linux-mag on cfq but illustrates how quantum works
"quantum
This parameter controls the number of dispatched requests to the device queue, request-device (i.e. the number of requests that are executed or at least sent for execution). In a queue’s time slice, a request will not be dispatched if the number of requests in the device request-device exceeds this parameter.
Just had to quote all that again to say, wow! Good read. Thanks for that brother!
I do NOT answer technical questions via PM. Post your question in the correct thread if you want a response.




The Following User Says Thank You to osm0sis For This Useful Post: [ Click to Expand ]
 
bigknowz
Old
#39447  
bigknowz's Avatar
Senior Member
Thanks Meter 145
Posts: 382
Join Date: Jan 2012
Location: NYC
Question Defaults changing

Quote:
Originally Posted by malaroth View Post
It differs as to which scheduler you're using but they all use algorithms to determine priority. That's where quantum is referenced. It's pretty tough unless you're a math whiz to nail down the perfect numbers but... what I did with my values was to determine if the current row values were too tough on writes or not tough enough on reads. We want our devices snappy and smooth. We don't want to see the device "processing", just know that it's happening in the background. So with that said I decided to lower the regular priority reads just a quarter to not clog the whole io with reads. The lag is coming from writes not getting finished so I increased the synchronous writes (ones that merge together) in the order of priority I felt would be most beneficial without totally eliminating the row function of read over write. In fact increasing read_idle increases io throughput since the idle function is to wait for higher priority data that hadn't been served when the process started but came in between. So instead of sticking it back in the queue it goes ahead and processes it. Increasing read_idle_freq allows more processes to be assigned into that queue. Now the document you got that from states that the default is 8ms... that's not for android. Each device is different. For the Gnex it's 7ms and increases in increments of 8ms. On the n7 default is 10ms with 10 ms increments. We've found that one step above default is the sweet spot. When I first brought these numbers to Franco he was very skeptical. Then he did some hardcore io testing and the numbers just showed better performance.

Edit* this is from Linux-mag on cfq but illustrates how quantum works
"quantum
This parameter controls the number of dispatched requests to the device queue, request-device (i.e. the number of requests that are executed or at least sent for execution). In a queue’s time slice, a request will not be dispatched if the number of requests in the device request-device exceeds this parameter.

Franco r365
JBSourcery 4.5.5
Are these tweaks being worked into ROW for r366?

Nexus 5 32GB
stock + GravityBox + a fargin kernel
Color Notifications for N5 (should work on any xxhdpi device)

*** retired ****
LTE Galaxy Nexus
 
Khrushy
Old
(Last edited by Khrushy; 21st February 2013 at 01:53 AM.)
#39448  
Khrushy's Avatar
Senior Member
Thanks Meter 333
Posts: 499
Join Date: Oct 2007
Location: Seoul, South Korea
Default Re: [KERNEL][GPL][GN] franco.Kernel

Great read Malaroth!
Madness takes its toll. Please have exact change.
 
bigknowz
Old
(Last edited by bigknowz; 21st February 2013 at 02:08 AM.) Reason: wording
#39449  
bigknowz's Avatar
Senior Member
Thanks Meter 145
Posts: 382
Join Date: Jan 2012
Location: NYC
Thumbs up Deadline

Quote:
Originally Posted by osm0sis View Post
Looks good, only thing is the iosched tunables tend to not work via init.d unless you put in a sleep to make the script wait to perform the commands, so I'd put them at the end, with a sleep 35 before. Really though, those are the defaults in r365 so you don't need to set them via init.d at all.

So far we think so, yeah. malaroth and franco are still tweaking some things but they're pretty much the same. boostpulse_duration was 80000 in r364, and is 100000 in r365, but we always have boost set to 0 (off) so it doesn't matter.
Trying out Deadline Scheduler tweaks via script

read_expire: 351
write_expire: 3500
writes_starved: 6
front_merges: 1
fifo_batch: 1

Thanks for the suggestions. Are they purely for performance?

Nexus 5 32GB
stock + GravityBox + a fargin kernel
Color Notifications for N5 (should work on any xxhdpi device)

*** retired ****
LTE Galaxy Nexus
 
reysonance
Old
(Last edited by reysonance; 21st February 2013 at 02:42 AM.)
#39450  
Senior Member
Thanks Meter 119
Posts: 259
Join Date: Nov 2012
@malaroth, I have been running your ROW tweaks for a full 24 hour now, initial impression is pretty good, there's noticeable improvement, although deadline is still a tad bit smoother, it doesn't struggle as much when writing apps to /data for example, I can still smoothly type on the keyboard (It still stutters though) while Play Store is updating a bunch of apps, as well as installing large games. Of course that's just some very basic testing without enough sample for a proper result, I'll try it for a few more days and see how it goes.

The Following 2 Users Say Thank You to reysonance For This Useful Post: [ Click to Expand ]
Tags
4.0.4, 4.1, 4.2, best kernel, best support, fast, franco, galaxy, jb 4.1, kernel, nexus, samsung
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes