{"push_id":1436367301,"size":4,"distinct_size":4,"ref":"refs/heads/marshmallow-6.0.1-release-lux","head":"0404a8bc93ff03b836a9432ad17c3370cfd7b245","before":"901e7a551bb3b2f453b359ee5234a028d9a368fc","commits":[{"sha":"996a7cb1edeaf0f2b41ea4bcc9b5c508fbcc8328","author":{"name":"Neal Cardwell","email":"6eb0de8c52d8a3fcaae13b97cd10ce8592d0bd4f@google.com"},"message":"tcp: fix timing issue in CUBIC slope calculation\n\nThis patch fixes a bug in CUBIC that causes cwnd to increase slightly\ntoo slowly when multiple ACKs arrive in the same jiffy.\n\nIf cwnd is supposed to increase at a rate of more than once per jiffy,\nthen CUBIC was sometimes too slow. Because the bic_target is\ncalculated for a future point in time, calculated with time in\njiffies, the cwnd can increase over the course of the jiffy while the\nbic_target calculated as the proper CUBIC cwnd at time\nt=tcp_time_stamp+rtt does not increase, because tcp_time_stamp only\nincreases on jiffy tick boundaries.\n\nSo since the cnt is set to:\n\tca->cnt = cwnd / (bic_target - cwnd);\nas cwnd increases but bic_target does not increase due to jiffy\ngranularity, the cnt becomes too large, causing cwnd to increase\ntoo slowly.\n\nFor example:\n- suppose at the beginning of a jiffy, cwnd=40, bic_target=44\n- so CUBIC sets:\n   ca->cnt =  cwnd / (bic_target - cwnd) = 40 / (44 - 40) = 40/4 = 10\n- suppose we get 10 acks, each for 1 segment, so tcp_cong_avoid_ai()\n   increases cwnd to 41\n- so CUBIC sets:\n   ca->cnt =  cwnd / (bic_target - cwnd) = 41 / (44 - 41) = 41 / 3 = 13\n\nSo now CUBIC will wait for 13 packets to be ACKed before increasing\ncwnd to 42, insted of 10 as it should.\n\nThe fix is to avoid adjusting the slope (determined by ca->cnt)\nmultiple times within a jiffy, and instead skip to compute the Reno\ncwnd, the \"TCP friendliness\" code path.\n\nReported-by: Eyal Perry <eyalpe@mellanox.com>\nSigned-off-by: Neal Cardwell <ncardwell@google.com>\nSigned-off-by: Yuchung Cheng <ycheng@google.com>\nSigned-off-by: Eric Dumazet <edumazet@google.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: vmantomecca <vmantomecca@gmail.com>","distinct":true,"url":"https://api.github.com/repos/vmantomecca/kernel-msm/commits/996a7cb1edeaf0f2b41ea4bcc9b5c508fbcc8328"},{"sha":"877eb0f4471aabeccf911473e321ecc0d28e06bf","author":{"name":"Eric Dumazet","email":"b3d77ad2db30f558882cc0c038be5a3cf96611f9@google.com"},"message":"tcp_cubic: better follow cubic curve after idle period\n\nJana Iyengar found an interesting issue on CUBIC :\n\nThe epoch is only updated/reset initially and when experiencing losses.\nThe delta \"t\" of now - epoch_start can be arbitrary large after app idle\nas well as the bic_target. Consequentially the slope (inverse of\nca->cnt) would be really large, and eventually ca->cnt would be\nlower-bounded in the end to 2 to have delayed-ACK slow-start behavior.\n\nThis particularly shows up when slow_start_after_idle is disabled\nas a dangerous cwnd inflation (1.5 x RTT) after few seconds of idle\ntime.\n\nJana initial fix was to reset epoch_start if app limited,\nbut Neal pointed out it would ask the CUBIC algorithm to recalculate the\ncurve so that we again start growing steeply upward from where cwnd is\nnow (as CUBIC does just after a loss). Ideally we'd want the cwnd growth\ncurve to be the same shape, just shifted later in time by the amount of\nthe idle period.\n\nChange-Id: Ia99e2743517729b1c0589fbb8db9965ec806043b\nReported-by: Jana Iyengar <jri@google.com>\nSigned-off-by: Eric Dumazet <edumazet@google.com>\nSigned-off-by: Yuchung Cheng <ycheng@google.com>\nSigned-off-by: Neal Cardwell <ncardwell@google.com>\nCc: Stephen Hemminger <stephen@networkplumber.org>\nCc: Sangtae Ha <sangtae.ha@gmail.com>\nCc: Lawrence Brakmo <lawrence@brakmo.org>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Andrea Arcangeli <aarcange@redhat.com>\nSigned-off-by: vmantomecca <vmantomecca@gmail.com>","distinct":true,"url":"https://api.github.com/repos/vmantomecca/kernel-msm/commits/877eb0f4471aabeccf911473e321ecc0d28e06bf"},{"sha":"7114137528601b8440314b52a990e1631db7daa6","author":{"name":"Eric Dumazet","email":"b3d77ad2db30f558882cc0c038be5a3cf96611f9@google.com"},"message":"tcp_cubic: do not set epoch_start in the future\n\nTracking idle time in bictcp_cwnd_event() is imprecise, as epoch_start\nis normally set at ACK processing time, not at send time.\n\nDoing a proper fix would need to add an additional state variable,\nand does not seem worth the trouble, given CUBIC bug has been there\nforever before Jana noticed it.\n\nLet's simply not set epoch_start in the future, otherwise\nbictcp_update() could overflow and CUBIC would again\ngrow cwnd too fast.\n\nThis was detected thanks to a packetdrill test Neal wrote that was flaky\nbefore applying this fix.\n\nChange-Id: I600d3a8ac0ed1d70f3ff5cc6b7341ac13178f4f3\nFixes: 30927520dbae (\"tcp_cubic: better follow cubic curve after idle period\")\nSigned-off-by: Eric Dumazet <edumazet@google.com>\nSigned-off-by: Neal Cardwell <ncardwell@google.com>\nSigned-off-by: Yuchung Cheng <ycheng@google.com>\nCc: Jana Iyengar <jri@google.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: Andrea Arcangeli <aarcange@redhat.com>\nSigned-off-by: vmantomecca <vmantomecca@gmail.com>","distinct":true,"url":"https://api.github.com/repos/vmantomecca/kernel-msm/commits/7114137528601b8440314b52a990e1631db7daa6"},{"sha":"0404a8bc93ff03b836a9432ad17c3370cfd7b245","author":{"name":"Yuchung Cheng","email":"e9603dd2756952b85012eef69eadebbcaf13f45b@google.com"},"message":"tcp: enable sockets to use MSG_FASTOPEN by default\n\nApplications have started to use Fast Open (e.g., Chrome browser has\nsuch an optional flag) and the feature has gone through several\ngenerations of kernels since 3.7 with many real network tests. It's\ntime to enable this flag by default for applications to test more\nconveniently and extensively.\n\nSigned-off-by: Yuchung Cheng <ycheng@google.com>\nSigned-off-by: Neal Cardwell <ncardwell@google.com>\nAcked-by: Eric Dumazet <edumazet@google.com>\nSigned-off-by: David S. Miller <davem@davemloft.net>\nSigned-off-by: vmantomecca <vmantomecca@gmail.com>","distinct":true,"url":"https://api.github.com/repos/vmantomecca/kernel-msm/commits/0404a8bc93ff03b836a9432ad17c3370cfd7b245"}]}
{"actor":{"display_login":"vmantomecca"}}