Test Builds: Automatic Scaling Interactive

[franciscofranco1990]

Hey guys. I started a different development few days ago on Mako, I built some routines to scale the interactive tunables on the go based on the average load of the cpu. It works similar to dyn interactive, but much less overhead and of course I built it from scratch so I have control over what I'm doing.

Currently Mako is an oblivious success, getting improvements as much as 5 or 6fps boost in some games and the device seems to be cooler and more battery friendly when the load is not that big.

I have two options here:

1 - scale up/down tunables based on percentage and its all automatic and no need for static values (not sure this is viable in the long run divisions and multiplications in the kernel that often is a lot of overhead).

2 - we create static values and its much more convenient.

The code that scales the values is very simple:

if (load >= 85 && !flag) {

    above_hispeed_delay[0] = 0;

    go_hispeed_load = 70;

    hispeed_freq = policy->max;

    min_sample_time = 80000;

    timer_rate = 10000;

    target_loads[0] = 60;

    load_flag = true;

    } else {

    above_hispeed_delay[0] = 50000;

    go_hispeed_load = 95;

    hispeed_freq = 1036000;

    min_sample_time = 20000;

    timer_rate = 15000;

    target_loads[0] = 85;

    load_flag = false;

    }

Of course that function is called in the interactive timer where I had to code a simple ringbuffer to calculate the average load, pass the load through parameter and then based on the load it scales the tunables up and down.

The values in there (this is what I just coded for Tuna, Mako is different) are placeholders. My goal is to have very conservative values during low load, and very very very aggressive values for maximum smoothness when gaming if the load is big.

Feedback on this?

[Zach (malaroth)]

I'd like to test the tuna ones to see how conservative we can go without getting the "my screen lags when turning it on" crap as well as high load gaming. I've never had issues with NFS:MW and I could test out the scaling with that. Got a test build or will it run as a script?

[Paul (pkgnex)]

Interesting concept, Franco.  The placeholder parameters seem reasonable and I'd like to test drive it.

My guess is that the devil will be in the details of how long a time step you use over which to average the "load" parameter.  It looks to me like as this delta-t reduces, your function may behave more and more like the unaltered Interactive governor with the hispeed_freq equal to the max frequency and with a 0.8 sec min_sample_time.  Or maybe I am misunderstanding how your function interacts with the governor?

[franciscofranco1990]

Yeah something like that. Here goes the boot.img:

http://minooch.com/franciscofranco/Galaxy%20Nexus/JB/JB-4.2.2/tests/boot.img

[Chris (osm0sis)]

Yeah this is crazy cool. :)

 

Are you going to implement the other simple changes first so you can go M5 on tuna and then go experimental with this after?

[Joaquín (joaquinf)]

What a nice surprise after a long time being MIA. Just flashed this test version and i'll stress the s***t out of it so i can give proper feedback.

Thanks francisco and all you guys for such a great dedication on bringing this kernel to another level :)

[franciscofranco1990]

Chris I'm not sure yet. I really wanted to deploy a Milestone with this feature. Is the boot.img above Milestone material?

[Joaquín (joaquinf)]

It sure is. This is the best I've felt my phone so far. Could you please take a look at those little things you forgot to include on the latest milestone so they are included on the milestone? Chris will give you more details on that, he's been reminding you but somehow they are some things left out.

This all new interactive feels great. One question though, how long it takes for the app to show the adjusted tuneables?, I've seen some differences in the original numbers you've posted when I check back on the app to see if they are correctly applied. I'm gonna try to recreate it and post some screenshots.

[Chris (osm0sis)]

I'll try it out shortly. Trying to pick subjective favs for deadline (tough!) with r374-osmod first, then I'll flash it and see if there's anything missing. ;)

[Joaquín (joaquinf)]

Definitely not seeing the "under high load" values being applied on the app, not even while running an an tutu benchmark test. Not sure if this is normal or not.

Not much of a benchmark guy here, but these look pretty good to me

http://i.imgur.com/19T2Uyv.png
http://i.imgur.com/JHZa4xD.png

[franciscofranco1990]

By the time you open the app the load is already so low that the values are already back to normal.

[Chris (osm0sis)]

Hmm well this is awesome but I'd like to see a fixed "r374" officially go out first. I don't really care if it's not a milestone. Maybe throw in the cfq finalists? Guys are reflashing their ROMs and starting to notice the PowerHAL replacement isn't working. So if we're going to go experimental I still think it's much better to have the build preceding it to be a good one.

[Joaquín (joaquinf)]

I have to say that i fully agree with chris on this one. 

On a different note, this are the batt life results after my heavy testing yesterday. Using both wifi and 3g all the time, some bluetooth streaming, whatsapp messaging, web and g+ app browsing, reddit and a couple of antutu bench --> http://imgur.com/a/MJZOU 

Performance is really good, however sometimes i could perceive some lag when typing on swiftkey. Other than that this test boot-img is awesome, battery life is great (i almost made it to 4 hours screen on time). 

[Paul (pkgnex)]

3rd vote in favor of Chris' suggestion.

Implement the few fixes for r374 and make that a milestone... make the new auto-tune governor the next experimental.  The test version (388) is working well for me so far, but I can't say that it's any better than r374.  It may just be the way I usually run my frequencies, though.  I don't have enough time with it to make a final call, though.

[Chris (osm0sis)]

Franco wants the auto-tune included in the milestone, so honestly it's totally fine if the fixed version is just a regular nightly r375. Then either public test build with auto-tune, nightly with auto-tune or straight to M5 with auto-tune is all fine with me. As long as we've got r375 without it and it's got the fixes and hardcoded tunables r374 didn't have.

[franciscofranco1990]

Sure, I'll do it now.

[Chris (osm0sis)]

Sweet. I'm up if you want to send it my way for a once over before it goes out the door. :)

[franciscofranco1990]

Its ok, its out up and running. Will now compile something post M5 with the same automatic scaling as the boot.img I posted here + BFQ v6 as you guys requested. Hang on.

[Chris (osm0sis)]

Haha on it. Thanks Francisco!

[Chris (osm0sis)]

the cfq tunables are all fucked. Might have to do a retry on r375.

[franciscofranco1990]

I copied what was in this thread into the kernel source :(

[Chris (osm0sis)]

Yeah I think it's something funky to do with those calculations on the lines that are messed up ,

 

static const int cfq_fifo_expire[2] = { HZ / 4, HZ / 8 };

static const int cfq_slice_sync = HZ / 10;

static int cfq_slice_async = HZ / 25;

[franciscofranco1990]

HZ = 128

I'll double check that fucking CFQ.

[Chris (osm0sis)]

Weird, and that somehow that ends up as

 

125
250

93
39

 

on Tuna by default... I'm guessing if we can work their equation backwards this way we'll find what we need for it to be 80/330/60/50

[Chris (osm0sis)]

I think static const int cfq_fifo_expire[2] = { 80, 330}; has them in the wrong order, since what we're getting (2578 / 625) is roughly 330 * 8, 80 * 8.

[franciscofranco1990]

Yah thats strange:

New boot.img based on r375 with BFQv6 and automatic scaling.

http://minooch.com/franciscofranco/Galaxy%20Nexus/JB/JB-4.2.2/tests/boot.img

[franciscofranco1990]

GRR. I will test tomorrow, its 1am, gotta get up at 8am for work. :)

[Chris (osm0sis)]

Crazy thing is it's not exactly 330.. it's 322.25 ... and 625 / 8 isn't 80, it's 78.125 - so they're doing something odd with the numbers where they both end up at roughly 0.9765.

[Chris (osm0sis)]

Yeah they're all ~ 8x too big.. so maybe if we just divide our original values for these by 8 (and swap the order for the fifo) we'll be in business.

 

Try:

 

static const int cfq_fifo_expire[2] = { 41.25, 10};

static const int cfq_slice_sync = 7.5;

static int cfq_slice_async = 6.25;

 

C'mooon franco, one more compile before bedtime. ;) :D

[Chris (osm0sis)]

Oh.. and

 

ui_print("Thanks Chris aka osm0sis for protecting against users mistake.");

 

should be

 

# Thanks Chris aka osm0sis for protecting against users mistake.

 

;)

 

I don't want you to mess up your gag by throwing silly thanks in there. Especially when that's really easy edify stuff. No credit needed/wanted. So you could remove it entirely / just go with the ones I emailed you that don't have that and I'd be fine. :)

 

[Chris (osm0sis)]

aaaand balls. :(

 

* Fix the PowerHAL not being set properly on boot, my derp sorry guys

 

 

Still not fixed. :/

 

It's still named sbin/fixtunapower.sh and the one that's in there is a very old one, not the fixed fkbootscript.sh one I emailed you.

 

Edit: Oh wait.. you just added a second call to fixtunapower.sh in init.rc instead. :P Please remove that new call and use the fkbootscript.sh I sent you. ;)

It doesn't have any of that old "wait for android os" bullshit that isn't necessary anymore. Attached.

[franciscofranco1990]

Ok. Thanks man.

Will do that after work.

[franciscofranco1990]

Chris, test it out: http://minooch.com/franciscofranco/Galaxy%20Nexus/JB/JB-4.2.2/tests/boot.img

This is r376 with the proposed changes and without the automatic scaling. 

[Chris (osm0sis)]

On it. Just finished my workout. Downloading now.

[Chris (osm0sis)]

We're close! 78/320/54/46 ... Lemme work out some new values.. :D

[Chris (osm0sis)]

The exact multiplier can't be 8.. must be something retarded like 7.65 .. seeing if I can work it out.

[Chris (osm0sis)]

I think the multiplier changes depending on the magnitude... That or it's slightly different for fifo and slice. I'm also not sure it even accepts decimal values since that's the only way there could be a single value they get multiplied by.

Let's try:

static const int cfq_fifo_expire[2] = { 43, 10.25};
static const int cfq_slice_sync = 7.75;
static int cfq_slice_async = 6.5;

:)

[Chris (osm0sis)]

Oh and everything else is perfect by the way! Thank you so much Francisco. :)

Maybe just remove the date from /sbin/fkbootscript.sh - I definitely appreciate you adding the credits in there even though it wasn't in the one I sent you. I'm sure the guys will appreciate having their handles buried in an official franco.Kernel too. :D

But yeah, you can lose the date in the comment at the top; it's just general queue tweaks and other little bits of script I wrote so it won't be changing much/ever. ;)

[franciscofranco1990]

Sure, will try those values. :)

[Chris (osm0sis)]

K I'm heading to bed. It's after 1am here. If you want to crank out another test build with those, I'll check it out in the morning and see if we have gotten any closer to nailing it. :)

[franciscofranco1990]

Wait! I just pushed a new one, same link, gogogo.

[Chris (osm0sis)]

Hahaha one second. Just decided to check if you'd replied one more time before heading off. :P

 

Edit: This has been some weird shit.

 

What we know:
         10 ->  78 {  71 ... 78 }
41.25 (41?) -> 320 { 313 ... 320 }
   7.5 (7?) ->  54 {  47 ... 54 }
  6.25 (6?) ->  46 {  40 ... 46 }

 

That works out to roughly a range of 313/41 = 7.63414634 to 46/6 = 7.66666667, but from the r375 outcomes we know that it increased to ~0.9765*8 = ~7.812 when the magnitude of the input values was increased. So the multiplier is a moving target. It would also only work out that they all share the same multiplier if it disregards the decimal point.. though 41 might still be large enough that it gets its own multiplier and will still be tricky and explain why it's been off by more.

 

Targets:
GN:                  N7:              Overlap:
 80 {  79 ... 85 }    {  71 ... 80 }   2
330 { 329 ... 335 }   { 321 ... 330 }  2
 60 {  55 ... 62 }    {  51 ... 60 }   6
 50 {  47 ... 54 }    {  41 ... 50 }   4

 

These small overlaps for our desired values make this tricky too, so if we can find the numbers here, hopefully it will still work over on the N7 and other devices but there's a chance it won't and we'll have to juke the numbers again.

[Chris (osm0sis)]

Okay looks like I might have been right about it disregarding decimals. The increased decimal points should have pushed it over to our desired ranges from what I worked out. If that is the case that means we'll have to go whole numbers and see where that gets us. Can we try this real quick?

 

static const int cfq_fifo_expire[2] = { 43, 11};
static const int cfq_slice_sync = 8;
static int cfq_slice_async = 7;

[franciscofranco1990]

Compiling!

[franciscofranco1990]

Same link.

[Chris (osm0sis)]

These are the winners:

 

static const int cfq_fifo_expire[2] = { 43, 11 };

static const int cfq_slice_sync = 8;
static int cfq_slice_async = 7;

 

:D

 

I think I just had a eureka moment about why the numbers are weird and how they work. I think they ARE the multiplier. Double checking my hypothesis now.

[franciscofranco1990]

Fabulastic! Time to release r376. Thanks Chris. In the mean time I also had updated interactive with two new patches and I'll release this one with BFQv6 as well as user request. I think this is Milestone. Then I'll start playing with automatic interactive tunables and thats a whole different playground.

[Chris (osm0sis)]

Yup! It's that FUCKING scale I semi-worked out before.

 

You'll recall on tuna the scale is something weird like y=7+8x, BUT that equation doesn't hold because every 5th (sometimes 6th) delta isn't 8, it's 7.

 

So that's why we get

 

  7, 15, 23, 31, 39, 46, 54, 62 [...]

 

/\  8    8    8    8    7    8    8  [...]

 

SO what those fucking cfq source numbers are doing is telling it exactly (n-1) how many deltas to jump to get the right number.

 

So we enter 8, and it jumps 7 deltas and gives us 62; we enter 7 and it jumps 6 deltas for 54.

 

 

That means on grouper it will be completely different, since the scales there are all 10s. Thankfully that also makes it easy.

 

I can predict for grouper:

static const int cfq_fifo_expire[2] = { 33, 8 };
static const int cfq_slice_sync = 6;
static int cfq_slice_async = 5;

 

And if I recall correctly, manta and mako are scales of 5, so just double those:

static const int cfq_fifo_expire[2] = { 66, 16 };
static const int cfq_slice_sync = 12;
static int cfq_slice_async = 10;

 

Thus concludes "Adventures In Computing" for the evening. :P

[Chris (osm0sis)]

Awesome franco. Make sure you've got the 43 in there for the first fifo number, I changed it to 42 for the last test but that was too low. 43 is it. :)

[franciscofranco1990]

I committed as 42 because thats what I read in the post, but I'll make it 43 on milestone, don't go into the thread and alarm them please, they only need to know what they believe, that will save me the trouble.

[Chris (osm0sis)]

Haha fair enough. It was 43 in the post though. My mistake for not pointing it out to you sooner I guess. :P

 

If anyone reading this is a little less rusty on their regression and quadratics and can work out the real equation for tuna, please do. (I'm looking at you Paul ;P)

[Chris (osm0sis)]

Francisco are you planning on giving r376 a few days in the wild to make sure there's nothing up with BFQv6? If so, we're getting close to finishing deadline so it'd be great to have those hardcoded in the milestone as well. Can we say.. end of this week, end of this weekend at the latest? A deadline for deadline? :D

[Stu (Khrushy)]

I think that sounds like a good plan. We should definitely have this stuff done by Friday.

[franciscofranco1990]

Yes sirs, by the weekend, then I want to tackle the automatic scaling on interactive that I've been working on Mako, I want it out for Tuna ASAP, and maybe Grouper.

[Paul (pkgnex)]

Chris,

I have to admit I'm lost in this conversation - not sure what you guys are talking about other than that the tunable numbers aren't sticking correctly in the kernel builds for some reason.

If you need help with some math, send me a direct e-mail with as much info as you can, and I should be able to work on it this evening.

[Chris (osm0sis)]

Thanks Paul! I just want to know the equation that defines how the variables on tuna increase. So when you enter something into any of the cfq tunables it goes from 7 to 15 to 23 and so on. Check my post where I talk about the deltas. It'll probably make a bit more sense now. I'll get you some data (will values up to 1000 be good probably?) with my testvalue.sh script and send it over. :D

[Paul (pkgnex)]

Can't (easily) find the post in question, so I'll await your data!

[Chris (osm0sis)]

The one that starts "Yup! It's that FUCKING scale I semi-worked out before," from 12 hours ago. :P

[Chris (osm0sis)]

Here's the data.

 

Edit: Actually hold on, I'll do you one better and make it already cut out the ones that don't matter.

 

Edit 2: Done. Raised the limit to 5000 as well.

 

Edit 3: The pattern of the jumps of 7 are every 5th delta, but every 3 of those it happens after the 6th delta. So fun? :P

[Paul (pkgnex)]

Os,

Here's the Excel formula:

y=TRUNC(x*7.8125)

So, basically, the resulting values are all integer multiples of 7.8125 with anything after the decimal place dropped.

Hope this helps!

[Chris (osm0sis)]

Cool! I managed to get that equation with the trendline in excel but since it wasn't giving me the exact values I disregarded it! :)

 

Does that hold for all the randomness of the jumping deltas?

[Paul (pkgnex)]

Yeah. But I borked the actual formula.

Take a column of whole numbers (0, 1, 2, 3, 4, etc.) then apply this formula and copy down:

TRUNC(value*7.8125,0)

It basically just chops off the decimal, and the values all EXACTLY match.

[Chris (osm0sis)]

Nice you're right! The weirdness in the delta jumps and everything. Thanks Paul! I knew you'd be able to get your head around this shit that I couldn't. :D

 

Funny though, I had that number from the very beginning! 8 * 0.9765 = 7.812 :P

[Paul (pkgnex)]

No problem, glad to help.

I started with some regression work, too, but found I had to increases the default Excel precision, then iterate on a new column while minimizing the absolute value of the delta to your values. Found I could force the error to always be between 0 and positive 0.9999, and TRUNC took care of the remainder.

[Chris (osm0sis)]

That also makes sense why in the GN cfq code it's

 

static const int cfq_fifo_expire[2] = { HZ / 4, HZ / 8 };

static const int cfq_slice_sync = HZ / 10;

static int cfq_slice_async = HZ / 25;

 

Francisco said HZ = 128

 

With fifo that gives us { 32, 16 } for delta #s, and that means 250, 125. The cfq defaults. :)

 

So either the cfq code must be different on the N7 or the HZ must be different.

[Paul (pkgnex)]

Os,

Just noticed that (1000 ÷ 1024) x 8 = 7.8125!

Therefore, I would bet the ratio has something to do with a sort of gigabyte / gibibyte type conversion. For example if the GN is coded in base 1000 but cfq was written in base 1024. I may have that scenario reversed, but you get the idea.

[Joaquín (joaquinf)]

Man that first test image with the dyntunective (buzzwords everywhere) is effing great. Performance is top notch. Excellent job Francisco, I'm looking forward to this new approach

Anything special you want me to test? It seems stable as hell

[Chris (osm0sis)]

Just checked /block/cfq-iosched.c on grouper, the code is exactly the same.. which must mean that HZ is different in order for it to be scaling by 10s and not 7s? I'm guessing HZ = 100 on grouper for it to be 10, and 200 on mako/manta for them to be 5?

[Chris (osm0sis)]

Alright Francisco, we're ready for M5 - deadline completed, and Paul did some quick optimizations to the bfq defaults for flash memory. :D

[franciscofranco1990]

Yep, coming up maybe today after Grouper!

[Chris (osm0sis)]

Francisco you decimated the grouper Testing / Issues thread! :O :)

 

Great job with r60 - only real issue now is UV and only suggestion I think it could use before being ready for milestone is a custom PowerHAL to allow for underclocking. :D

 

Edit: Oh and back to our winning N7 interactive tunables as defaults. ;)

[Chris (osm0sis)]

I'm just going to say I'm going to bed soon, because every time I go to sleep something happens and I miss the action! :P