{"push_id":817563224,"size":11,"distinct_size":11,"ref":"refs/heads/cm-12.1","head":"e84917c59a5ac354b1476c396f338a7eca890993","before":"f14f6084b182b175f0f7ade33bd1ccabd4bf11d7","commits":[{"sha":"6a0ca25f192c96f30deb363a180cbd3faccf9f7b","author":{"email":"c208d1ecece4e5ef2e4fb72f0546c69cdce89063@gmail.com","name":"Paul Reioux"},"message":"KGSL: make simple govenor a selectable option, co-exist with ondemand\n\nalso removed some hardcoded values\n\nSigned-off-by: Paul Reioux <reioux@gmail.com>\nSigned-off-by: flar2 <asegaert@gmail.com>","distinct":true,"url":"https://api.github.com/repos/Gabriel85/android_kernel_sony_apq8064/commits/6a0ca25f192c96f30deb363a180cbd3faccf9f7b"},{"sha":"27cdb7514772daa169fc16d574e0c8c688a896fe","author":{"email":"c208d1ecece4e5ef2e4fb72f0546c69cdce89063@gmail.com","name":"Paul Reioux"},"message":"KGSL: simple governor: expose tunables to sysfs interface via module_param\n\nSigned-off-by: Paul Reioux <reioux@gmail.com>\nSigned-off-by: flar2 <asegaert@gmail.com>","distinct":true,"url":"https://api.github.com/repos/Gabriel85/android_kernel_sony_apq8064/commits/27cdb7514772daa169fc16d574e0c8c688a896fe"},{"sha":"c4dac72d70795a9c68ebc49a059a5939c4547359","author":{"email":"c208d1ecece4e5ef2e4fb72f0546c69cdce89063@gmail.com","name":"Paul Reioux"},"message":"KGSL: Simple Governor: fix minor logic issue\n\nSigned-off-by: Paul Reioux <reioux@gmail.com>\nSigned-off-by: flar2 <asegaert@gmail.com>","distinct":true,"url":"https://api.github.com/repos/Gabriel85/android_kernel_sony_apq8064/commits/c4dac72d70795a9c68ebc49a059a5939c4547359"},{"sha":"2568b7650e674de401ffabd565c8f5874394c855","author":{"email":"50cb9bee76fd6567c3233b8a89e4a594c545792f@gmail.com","name":"flar2"},"message":"exFAT support\n\nSigned-off-by: flar2 <asegaert@gmail.com>","distinct":true,"url":"https://api.github.com/repos/Gabriel85/android_kernel_sony_apq8064/commits/2568b7650e674de401ffabd565c8f5874394c855"},{"sha":"0f71e4d076ce827c87e6d341224b4c6a2f33d3ba","author":{"email":"4d9e23a041ac966f5316a7481300d4ae12e806fe@redhat.com","name":"Dave Chinner"},"message":"sync: don't block the flusher thread waiting on IO\n\nWhen sync does it's WB_SYNC_ALL writeback, it issues data Io and\nthen immediately waits for IO completion. This is done in the\ncontext of the flusher thread, and hence completely ties up the\nflusher thread for the backing device until all the dirty inodes\nhave been synced. On filesystems that are dirtying inodes constantly\nand quickly, this means the flusher thread can be tied up for\nminutes per sync call and hence badly affect system level write IO\nperformance as the page cache cannot be cleaned quickly.\n\nWe already have a wait loop for IO completion for sync(2), so cut\nthis out of the flusher thread and delegate it to wait_sb_inodes().\nHence we can do rapid IO submission, and then wait for it all to\ncomplete.\n\nEffect of sync on fsmark before the patch:\n\nFSUse%        Count         Size    Files/sec     App Overhead\n.....\n     0       640000         4096      35154.6          1026984\n     0       720000         4096      36740.3          1023844\n     0       800000         4096      36184.6           916599\n     0       880000         4096       1282.7          1054367\n     0       960000         4096       3951.3           918773\n     0      1040000         4096      40646.2           996448\n     0      1120000         4096      43610.1           895647\n     0      1200000         4096      40333.1           921048\n\nAnd a single sync pass took:\n\n  real    0m52.407s\n  user    0m0.000s\n  sys     0m0.090s\n\nAfter the patch, there is no impact on fsmark results, and each\nindividual sync(2) operation run concurrently with the same fsmark\nworkload takes roughly 7s:\n\n  real    0m6.930s\n  user    0m0.000s\n  sys     0m0.039s\n\nIOWs, sync is 7-8x faster on a busy filesystem and does not have an\nadverse impact on ongoing async data write operations.\n\nSigned-off-by: Dave Chinner <dchinner@redhat.com>\nReviewed-by: Jan Kara <jack@suse.cz>\nSigned-off-by: Linus Torvalds <torvalds@linux-foundation.org>\nSigned-off-by: flar2 <asegaert@gmail.com>","distinct":true,"url":"https://api.github.com/repos/Gabriel85/android_kernel_sony_apq8064/commits/0f71e4d076ce827c87e6d341224b4c6a2f33d3ba"},{"sha":"bf7491b96be331df140bd7825db7e2fc6747763b","author":{"email":"df7da900ca6d4d8dc52d8adb26aa75aef11ea28b@intel.com","name":"ShuoX Liu"},"message":"cpuidle: move field disable from per-driver to per-cpu\n\nAndrew J.Schorr raises a question.  When he changes the disable setting on\na single CPU, it affects all the other CPUs.  Basically, currently, the\ndisable field is per-driver instead of per-cpu.  All the C states of the\nsame driver are shared by all CPU in the same machine.\n\nThe patch changes the `disable' field to per-cpu, so we could set this\nseparately for each cpu.\n\nSigned-off-by: ShuoX Liu <shuox.liu@intel.com>\nReported-by: Andrew J.Schorr <aschorr@telemetry-investments.com>\nReviewed-by: Yanmin Zhang <yanmin_zhang@intel.com>\nSigned-off-by: Andrew Morton <akpm@linux-foundation.org>\nSigned-off-by: flar2 <asegaert@gmail.com>","distinct":true,"url":"https://api.github.com/repos/Gabriel85/android_kernel_sony_apq8064/commits/bf7491b96be331df140bd7825db7e2fc6747763b"},{"sha":"162e339f331065cc896a0367cbbe2e8afaf6e657","author":{"email":"c197d3855265d85d241d4a166c50c0c05691a4d2@intel.com","name":"Youquan Song"},"message":"cpuidle: Quickly notice prediction failure for repeat mode\n\nThe prediction for future is difficult and when the cpuidle governor prediction\nfails and govenor possibly choose the shallower C-state than it should. How to\nquickly notice and find the failure becomes important for power saving.\n\ncpuidle menu governor has a method to predict the repeat pattern if there are 8\nC-states residency which are continuous and the same or very close, so it will\npredict the next C-states residency will keep same residency time.\n\nThere is a real case that turbostat utility (tools/power/x86/turbostat)\nat kernel 3.3 or early. turbostat utility will read 10 registers one by one at\nSandybridge, so it will generate 10 IPIs to wake up idle CPUs. So cpuidle menu\n governor will predict it is repeat mode and there is another IPI wake up idle\n CPU soon, so it keeps idle CPU stay at C1 state even though CPU is totally\nidle. However, in the turbostat, following 10 registers reading is sleep 5\nseconds by default, so the idle CPU will keep at C1 for a long time though it is\n idle until break event occurs.\nIn a idle Sandybridge system, run \"./turbostat -v\", we will notice that deep\nC-state dangles between \"70% ~ 99%\". After patched the kernel, we will notice\ndeep C-state stays at >99.98%.\n\nIn the patch, a timer is added when menu governor detects a repeat mode and\nchoose a shallow C-state. The timer is set to a time out value that greater\nthan predicted time, and we conclude repeat mode prediction failure if timer is\ntriggered. When repeat mode happens as expected, the timer is not triggered\nand CPU waken up from C-states and it will cancel the timer initiatively.\nWhen repeat mode does not happen, the timer will be time out and menu governor\nwill quickly notice that the repeat mode prediction fails and then re-evaluates\ndeeper C-states possibility.\n\nBelow is another case which will clearly show the patch much benefit:\n\nvolatile int * shutdown;\nvolatile long * count;\nint delay = 20;\nint loop = 8;\n\nvoid usage(void)\n{\n\tfprintf(stderr,\n\t\t\"Usage: idle_predict [options]\\n\"\n\t\t\"  --help\t-h  Print this help\\n\"\n\t\t\"  --thread\t-n  Thread number\\n\"\n\t\t\"  --loop     \t-l  Loop times in shallow Cstate\\n\"\n\t\t\"  --delay\t-t  Sleep time (uS)in shallow Cstate\\n\");\n}\n\nvoid *simple_loop() {\n\tint idle_num = 1;\n\twhile (!(*shutdown)) {\n\t\t*count = *count + 1;\n\n\t\tif (idle_num % loop)\n\t\t\tusleep(delay);\n\t\telse {\n\t\t\t/* sleep 1 second */\n\t\t\tusleep(1000000);\n\t\t\tidle_num = 0;\n\t\t}\n\t\tidle_num++;\n\t}\n\n}\n\nstatic void sighand(int sig)\n{\n\t*shutdown = 1;\n}\n\nint main(int argc, char *argv[])\n{\n\tsigset_t sigset;\n\tint signum = SIGALRM;\n\tint i, c, er = 0, thread_num = 8;\n\tpthread_t pt[1024];\n\n\tstatic char optstr[] = \"n:l:t:h:\";\n\n\twhile ((c = getopt(argc, argv, optstr)) != EOF)\n\t\tswitch (c) {\n\t\t\tcase 'n':\n\t\t\t\tthread_num = atoi(optarg);\n\t\t\t\tbreak;\n\t\t\tcase 'l':\n\t\t\t\tloop = atoi(optarg);\n\t\t\t\tbreak;\n\t\t\tcase 't':\n\t\t\t\tdelay = atoi(optarg);\n\t\t\t\tbreak;\n\t\t\tcase 'h':\n\t\t\tdefault:\n\t\t\t\tusage();\n\t\t\t\texit(1);\n\t\t}\n\n\tprintf(\"thread=%d,loop=%d,delay=%d\\n\",thread_num,loop,delay);\n\tcount = malloc(sizeof(long));\n\tshutdown = malloc(sizeof(int));\n\t*count = 0;\n\t*shutdown = 0;\n\n\tsigemptyset(&sigset);\n\tsigaddset(&sigset, signum);\n\tsigprocmask (SIG_BLOCK, &sigset, NULL);\n\tsignal(SIGINT, sighand);\n\tsignal(SIGTERM, sighand);\n\n\tfor(i = 0; i < thread_num ; i++)\n\t\tpthread_create(&pt[i], NULL, simple_loop, NULL);\n\n\tfor (i = 0; i < thread_num; i++)\n\t\tpthread_join(pt[i], NULL);\n\n\texit(0);\n}\n\nGet powertop V2 from git://github.com/fenrus75/powertop, build powertop.\nAfter build the above test application, then run it.\nTest plaform can be Intel Sandybridge or other recent platforms.\n\nWe will find that deep C-state will dangle between 40%~100% and much time spent\non C1 state. It is because menu governor wrongly predict that repeat mode\nis kept, so it will choose the C1 shallow C-state even though it has chance to\nsleep 1 second in deep C-state.\n\nWhile after patched the kernel, we find that deep C-state will keep >99.6%.\n\nSigned-off-by: Rik van Riel <riel@redhat.com>\nSigned-off-by: Youquan Song <youquan.song@intel.com>\nSigned-off-by: flar2 <asegaert@gmail.com>","distinct":true,"url":"https://api.github.com/repos/Gabriel85/android_kernel_sony_apq8064/commits/162e339f331065cc896a0367cbbe2e8afaf6e657"},{"sha":"857b89448fdab75ba6e4b7f4e39b8eb70b1473cc","author":{"email":"c197d3855265d85d241d4a166c50c0c05691a4d2@intel.com","name":"Youquan Song"},"message":"cpuidle: Quickly notice prediction failure in general case\n\nThe prediction for future is difficult and when the cpuidle governor prediction\nfails and govenor possibly choose the shallower C-state than it should. How to\nquickly notice and find the failure becomes important for power saving.\n\nThe patch extends to general case that prediction logic get a small predicted\nresidency, so it choose a shallow C-state though the expected residency is large\n. Once the prediction will be fail, the CPU will keep staying at shallow C-state\nfor a long time. Acutally, the CPU has change enter into deep C-state.\nSo when the expected residency is long enough but governor choose a shallow\nC-state, an timer will be added in order to monitor if the prediction failure.\n\nWhen C-state is waken up prior to the adding timer, the timer will be cancelled\ninitiatively. When the timer is triggered and menu governor will quickly notice\nprediction failure and re-evaluates deeper C-states possibility.\n\nSigned-off-by: Rik van Riel <riel@redhat.com>\nSigned-off-by: Youquan Song <youquan.song@intel.com>\nSigned-off-by: flar2 <asegaert@gmail.com>","distinct":true,"url":"https://api.github.com/repos/Gabriel85/android_kernel_sony_apq8064/commits/857b89448fdab75ba6e4b7f4e39b8eb70b1473cc"},{"sha":"c3608b68966d072630ef93de12e6b00c01cc9b50","author":{"email":"c197d3855265d85d241d4a166c50c0c05691a4d2@intel.com","name":"Youquan Song"},"message":"cpuidle: Get typical recent sleep interval\n\nThe function detect_repeating_patterns was not very useful for\nworkloads with alternating long and short pauses, for example\nvirtual machines handling network requests for each other (say\na web and database server).\n\nInstead, try to find a recent sleep interval that is somewhere\nbetween the median and the mode sleep time, by discarding outliers\nto the up side and recalculating the average and standard deviation\nuntil that is no longer required.\n\nThis should do something sane with a sleep interval series like:\n\n\t200 180 210 10000 30 1000 170 200\n\nThe current code would simply discard such a series, while the\nnew code will guess a typical sleep interval just shy of 200.\n\nThe original patch come from Rik van Riel <riel@redhat.com>.\n\nSigned-off-by: Rik van Riel <riel@redhat.com>\nSigned-off-by: Youquan Song <youquan.song@intel.com>\nSigned-off-by: flar2 <asegaert@gmail.com>","distinct":true,"url":"https://api.github.com/repos/Gabriel85/android_kernel_sony_apq8064/commits/c3608b68966d072630ef93de12e6b00c01cc9b50"},{"sha":"22f56244db912898ed5899ce47edf72772da7591","author":{"email":"b5ea082ce4fba4068bd1521bf6ad8c947e6a993f@nvidia.com","name":"Sivaram Nair"},"message":"cpuidle: Fix finding state with min power_usage\n\nSince cpuidle_state.power_usage is a signed value, use INT_MAX (instead\nof -1) to init the local copies so that functions that tries to find\ncpuidle states with minimum power usage works correctly even if they use\nnon-negative values.\n\nSigned-off-by: Sivaram Nair <sivaramn@nvidia.com>\nReviewed-by: Rik van Riel <riel@redhat.com>\nSigned-off-by: flar2 <asegaert@gmail.com>","distinct":true,"url":"https://api.github.com/repos/Gabriel85/android_kernel_sony_apq8064/commits/22f56244db912898ed5899ce47edf72772da7591"},{"sha":"e84917c59a5ac354b1476c396f338a7eca890993","author":{"email":"e9fa45941f2ebe89c1b9d6c5f339ab42eadb8567@linaro.org","name":"Daniel Lezcano"},"message":"cpuidle: remove the power_specified field in the driver\n\nWe realized that the power usage field is never filled and when it\nis filled for tegra, the power_specified flag is not set causing all\nof these values to be reset when the driver is initialized with\nset_power_state().\n\nHowever, the power_specified flag can be simply removed under the\nassumption that the states are always backward sorted, which is the\ncase with the current code.\n\nThis change allows the menu governor select function and the\ncpuidle_play_dead() to be simplified.  Moreover, the\nset_power_states() function can removed as it does not make sense\nany more.\n\nDrop the power_specified flag from struct cpuidle_driver and make\nthe related changes as described above.\n\nAs a consequence, this also fixes the bug where on the dynamic\nC-states system, the power fields are not initialized.\n\n[rjw: Changelog]\nReferences: https://bugzilla.kernel.org/show_bug.cgi?id=42870\nReferences: https://bugzilla.kernel.org/show_bug.cgi?id=43349\nReferences: https://lkml.org/lkml/2012/10/16/518\nSigned-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>\nSigned-off-by: flar2 <asegaert@gmail.com>","distinct":true,"url":"https://api.github.com/repos/Gabriel85/android_kernel_sony_apq8064/commits/e84917c59a5ac354b1476c396f338a7eca890993"}]}