I DO have tentative row tweaks... there's no guarantee they'll fully set on boot even with an init.d script but if you'd like to try...
900rowtweaks
They're far from being perfected but they DO feel a whole lot more smooth
Franco r365
JBSourcery 4.5.5
---------- Post added at 09:06 AM ---------- Previous post was at 08:54 AM ----------
But if you're gonna use them... please give me feedback. Lemme know where you get lag and hangups, it really shouldn't happen much but I need to know if I've lowered read priority too much or not increased write priority enough
Franco r365
JBSourcery 4.5.5
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