{"push_id":3749003115,"size":10,"distinct_size":10,"ref":"refs/heads/kernel-4.4","head":"80412c17d12aeabdb32624ee5117879b3865058c","before":"6f0f999020c68a817273ce7d347bec3b389c2280","commits":[{"sha":"2c342774aab3dc79e5437c6d024f6d5c4fbd32b3","author":{"name":"Sultan Alsawaf","email":"1ecf0d3b91a10748bf035efdc0fad552aefe2ade@kerneltoast.com"},"message":"proc: Don't let Google Camera and Settings run in the background\n\nGoogle Camera and Settings both burn through CPU in the background doing\nnothing useful. In the case of Google Camera, it keeps polling sensors\nin the background while it is doing nothing for the user.\n\nMeanwhile, in Settings, when leaving the Adaptive brightness activity\nvia any means other than using the back button (e.g., the home button),\nthe GIF in the Adaptive brightness activity will continue playing in the\nbackground. This bug applies to all of the dumb GIFs in Settings.\n\nKill both of these apps when they reach the background to stop them from\nburning through battery.\n\nSigned-off-by: Sultan Alsawaf <sultan@kerneltoast.com>","distinct":true,"url":"https://api.github.com/repos/whoknowswhoiam/weebmsm8998-pie/commits/2c342774aab3dc79e5437c6d024f6d5c4fbd32b3"},{"sha":"a5572b0049d190bb8f8eca39292b17cfde675779","author":{"name":"Sultan Alsawaf","email":"1ecf0d3b91a10748bf035efdc0fad552aefe2ade@kerneltoast.com"},"message":"Revert \"staging: sync: Don't allocate memory dynamically for fence info\"\n\nUh-oh, this ioctl does run in parallel/concurrently. This causes system\nfreezes.\n\nThis reverts commit f9dcff6db6cf3f3cfb87db882c2118961067aa49.","distinct":true,"url":"https://api.github.com/repos/whoknowswhoiam/weebmsm8998-pie/commits/a5572b0049d190bb8f8eca39292b17cfde675779"},{"sha":"00455670c4c26f6eef01bfcbdd295585d57f4c60","author":{"name":"idkwhoiam322","email":"cc61e0cd8e12a7060c339e7d3dbd1bea5b53581e@gmail.com"},"message":"Revert \"msm: kgsl: Relax CPU latency requirements to save power\"\n\nThis reverts commit 8b480f7d5ac267f814e32eb2f4ae692c3de29061.","distinct":true,"url":"https://api.github.com/repos/whoknowswhoiam/weebmsm8998-pie/commits/00455670c4c26f6eef01bfcbdd295585d57f4c60"},{"sha":"b9a12e82b669191ad567abd65a7621a49558e89f","author":{"name":"Sultan Alsawaf","email":"1ecf0d3b91a10748bf035efdc0fad552aefe2ade@kerneltoast.com"},"message":"msm: camera: Avoid dynamic memory allocation for small buffers\n\nTry to use an on-stack buffer for memory allocations that are small\nenough to not warrant a dynamic allocation. This improves performance by\nskipping latency-prone dynamic memory allocation when it isn't needed.\n\nSigned-off-by: Sultan Alsawaf <sultan@kerneltoast.com>","distinct":true,"url":"https://api.github.com/repos/whoknowswhoiam/weebmsm8998-pie/commits/b9a12e82b669191ad567abd65a7621a49558e89f"},{"sha":"4a7f826541de51efdd00b1d397e37352376430e3","author":{"name":"Sultan Alsawaf","email":"1ecf0d3b91a10748bf035efdc0fad552aefe2ade@kerneltoast.com"},"message":"media: v4l2-ioctl: Use a larger on-stack video copy buffer\n\nWe have a 16 KiB stack; a buffer of 1 KiB works perfectly fine in place\nof a small 128-byte buffer. This avoids dynamic memory allocation more\noften, improving performance.\n\nSigned-off-by: Sultan Alsawaf <sultan@kerneltoast.com>","distinct":true,"url":"https://api.github.com/repos/whoknowswhoiam/weebmsm8998-pie/commits/4a7f826541de51efdd00b1d397e37352376430e3"},{"sha":"551381613740ef6817f3a63ae21452bf56fbcaac","author":{"name":"Sultan Alsawaf","email":"1ecf0d3b91a10748bf035efdc0fad552aefe2ade@kerneltoast.com"},"message":"ALSA: control: Don't dynamically allocate a single struct instance\n\nThere's no reason to dynamically allocate this struct instance. Just put\nit on the stack instead to improve performance.\n\nSigned-off-by: Sultan Alsawaf <sultan@kerneltoast.com>","distinct":true,"url":"https://api.github.com/repos/whoknowswhoiam/weebmsm8998-pie/commits/551381613740ef6817f3a63ae21452bf56fbcaac"},{"sha":"f338cd045d29bfcfd580e439f1c50fed0fb99e0f","author":{"name":"Daniel Rosenberg","email":"b28fe47f344ea47a742972f6caa7ef1537d21708@google.com"},"message":"fs: sdcardfs: Add missing option to show_options\n\nunshared_obb was missing from show_options\n\nbug: 133257717\nChange-Id: I1bc49d1b4098052382a518540e5965e037aa39f1","distinct":true,"url":"https://api.github.com/repos/whoknowswhoiam/weebmsm8998-pie/commits/f338cd045d29bfcfd580e439f1c50fed0fb99e0f"},{"sha":"0121fb5a329b9d8fad54b8d313744ec92bb6d695","author":{"name":"Roman Kiryanov","email":"53acac3ce35cdf9c64ac76f31a39998694656e27@google.com"},"message":"ANDROID: kernel: cgroup: cpuset: Add missing allocation of cpus_requested in alloc_trial_cpuset\n\nalloc_trial_cpuset missed allocation of the alloc_trial_cpuset\nfield which caused it to be shared from the base cs provided.\n\nOnce update_cpumask parsed buf into cpus_requested and updated\ncpus_allowed, the result were never written to cs because\ncs and trialcs shared the same pointer to cpus_requested and\ncpus_requested always matched to itself and no updates were\nwritten. This caused cpus_requested to be non-empty and\ncpus_allowed empty.\n\nThis issue occurs only with CONFIG_CPUMASK_OFFSTACK enabled\n(e.g. via CONFIG_MAXSMP).\n\nBug: 134051784\nBug: 120444281\nFixes: 4803def4e0b2 (\"ANDROID: cpuset: Make cpusets restore on hotplug\")\nTest: enable CONFIG_CPUSETS, boot and check logcat that\nTest: libprocessgroup does not fail with something similar to\nTest: AddTidToCgroup failed to write '2354'; fd=93: No space left on device\nSigned-off-by: Roman Kiryanov <rkir@google.com>\nChange-Id: I866836b5c0acfde8349c250a510ee89d8d37cb8e","distinct":true,"url":"https://api.github.com/repos/whoknowswhoiam/weebmsm8998-pie/commits/0121fb5a329b9d8fad54b8d313744ec92bb6d695"},{"sha":"67f969ea898e57a2ca939828a6ad97a9a3df99ea","author":{"name":"Roman Kiryanov","email":"53acac3ce35cdf9c64ac76f31a39998694656e27@google.com"},"message":"ANDROID: kernel: cgroup: cpuset: Clear cpus_requested for empty buf\n\nupdate_cpumask had a special case for empty buf which\ndid not update cpus_requested. This change reduces\ndifferences (only to parsing) in empty/non-empty codepaths\nto make them consistent.\n\nBug: 120444281\nFixes: 4803def4e0b2 (\"ANDROID: cpuset: Make cpusets restore on hotplug\")\nTest: check that writes to /dev/cpuset/background/tasks\nTest: work as expected, e.g.:\nTest: echo $$ > /dev/cpuset/background/tasks\nTest: echo > /dev/cpuset/background/tasks\nSigned-off-by: Roman Kiryanov <rkir@google.com>\nChange-Id: I49d320ea046636ec38bd23f053317abc59f64f8e","distinct":true,"url":"https://api.github.com/repos/whoknowswhoiam/weebmsm8998-pie/commits/67f969ea898e57a2ca939828a6ad97a9a3df99ea"},{"sha":"80412c17d12aeabdb32624ee5117879b3865058c","author":{"name":"Neal Cardwell","email":"58d301c70203188c35d379474c26c9cc0636a189@google.com"},"message":"tcp_bbr: add BBR congestion control\n\nThis commit implements a new TCP congestion control algorithm: BBR\n(Bottleneck Bandwidth and RTT). A detailed description of BBR will be\npublished in ACM Queue, Vol. 14 No. 5, September-October 2016, as\n\"BBR: Congestion-Based Congestion Control\".\n\nBBR has significantly increased throughput and reduced latency for\nconnections on Google's internal backbone networks and google.com and\nYouTube Web servers.\n\nBBR requires only changes on the sender side, not in the network or\nthe receiver side. Thus it can be incrementally deployed on today's\nInternet, or in datacenters.\n\nThe Internet has predominantly used loss-based congestion control\n(largely Reno or CUBIC) since the 1980s, relying on packet loss as the\nsignal to slow down. While this worked well for many years, loss-based\ncongestion control is unfortunately out-dated in today's networks. On\ntoday's Internet, loss-based congestion control causes the infamous\nbufferbloat problem, often causing seconds of needless queuing delay,\nsince it fills the bloated buffers in many last-mile links. On today's\nhigh-speed long-haul links using commodity switches with shallow\nbuffers, loss-based congestion control has abysmal throughput because\nit over-reacts to losses caused by transient traffic bursts.\n\nIn 1981 Kleinrock and Gale showed that the optimal operating point for\na network maximizes delivered bandwidth while minimizing delay and\nloss, not only for single connections but for the network as a\nwhole. Finding that optimal operating point has been elusive, since\nany single network measurement is ambiguous: network measurements are\nthe result of both bandwidth and propagation delay, and those two\ncannot be measured simultaneously.\n\nWhile it is impossible to disambiguate any single bandwidth or RTT\nmeasurement, a connection's behavior over time tells a clearer\nstory. BBR uses a measurement strategy designed to resolve this\nambiguity. It combines these measurements with a robust servo loop\nusing recent control systems advances to implement a distributed\ncongestion control algorithm that reacts to actual congestion, not\npacket loss or transient queue delay, and is designed to converge with\nhigh probability to a point near the optimal operating point.\n\nIn a nutshell, BBR creates an explicit model of the network pipe by\nsequentially probing the bottleneck bandwidth and RTT. On the arrival\nof each ACK, BBR derives the current delivery rate of the last round\ntrip, and feeds it through a windowed max-filter to estimate the\nbottleneck bandwidth. Conversely it uses a windowed min-filter to\nestimate the round trip propagation delay. The max-filtered bandwidth\nand min-filtered RTT estimates form BBR's model of the network pipe.\n\nUsing its model, BBR sets control parameters to govern sending\nbehavior. The primary control is the pacing rate: BBR applies a gain\nmultiplier to transmit faster or slower than the observed bottleneck\nbandwidth. The conventional congestion window (cwnd) is now the\nsecondary control; the cwnd is set to a small multiple of the\nestimated BDP (bandwidth-delay product) in order to allow full\nutilization and bandwidth probing while bounding the potential amount\nof queue at the bottleneck.\n\nWhen a BBR connection starts, it enters STARTUP mode and applies a\nhigh gain to perform an exponential search to quickly probe the\nbottleneck bandwidth (doubling its sending rate each round trip, like\nslow start). However, instead of continuing until it fills up the\nbuffer (i.e. a loss), or until delay or ACK spacing reaches some\nthreshold (like Hystart), it uses its model of the pipe to estimate\nwhen that pipe is full: it estimates the pipe is full when it notices\nthe estimated bandwidth has stopped growing. At that point it exits\nSTARTUP and enters DRAIN mode, where it reduces its pacing rate to\ndrain the queue it estimates it has created.\n\nThen BBR enters steady state. In steady state, PROBE_BW mode cycles\nbetween first pacing faster to probe for more bandwidth, then pacing\nslower to drain any queue that created if no more bandwidth was\navailable, and then cruising at the estimated bandwidth to utilize the\npipe without creating excess queue. Occasionally, on an as-needed\nbasis, it sends significantly slower to probe for RTT (PROBE_RTT\nmode).\n\nBBR has been fully deployed on Google's wide-area backbone networks\nand we're experimenting with BBR on Google.com and YouTube on a global\nscale.  Replacing CUBIC with BBR has resulted in significant\nimprovements in network latency and application (RPC, browser, and\nvideo) metrics. For more details please refer to our upcoming ACM\nQueue publication.\n\nExample performance results, to illustrate the difference between BBR\nand CUBIC:\n\nResilience to random loss (e.g. from shallow buffers):\n  Consider a netperf TCP_STREAM test lasting 30 secs on an emulated\n  path with a 10Gbps bottleneck, 100ms RTT, and 1% packet loss\n  rate. CUBIC gets 3.27 Mbps, and BBR gets 9150 Mbps (2798x higher).\n\nLow latency with the bloated buffers common in today's last-mile links:\n  Consider a netperf TCP_STREAM test lasting 120 secs on an emulated\n  path with a 10Mbps bottleneck, 40ms RTT, and 1000-packet bottleneck\n  buffer. Both fully utilize the bottleneck bandwidth, but BBR\n  achieves this with a median RTT 25x lower (43 ms instead of 1.09\n  secs).\n\nOur long-term goal is to improve the congestion control algorithms\nused on the Internet. We are hopeful that BBR can help advance the\nefforts toward this goal, and motivate the community to do further\nresearch.\n\nTest results, performance evaluations, feedback, and BBR-related\ndiscussions are very welcome in the public e-mail list for BBR:\n\n  https://groups.google.com/forum/#!forum/bbr-dev\n\nNOTE: BBR *must* be used with the fq qdisc (\"man tc-fq\") with pacing\nenabled, since pacing is integral to the BBR design and\nimplementation. BBR without pacing would not function properly, and\nmay incur unnecessary high packet loss rates.\n\nSigned-off-by: Van Jacobson <vanj@google.com>\nSigned-off-by: Neal Cardwell <ncardwell@google.com>\nSigned-off-by: Yuchung Cheng <ycheng@google.com>\nSigned-off-by: Nandita Dukkipati <nanditad@google.com>\nSigned-off-by: Eric Dumazet <edumazet@google.com>\nSigned-off-by: Soheil Hassas Yeganeh <soheil@google.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>","distinct":true,"url":"https://api.github.com/repos/whoknowswhoiam/weebmsm8998-pie/commits/80412c17d12aeabdb32624ee5117879b3865058c"}]}
{"actor":{"display_login":"whoknowswhoiam"}}