git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Stochastic bisection support

From
JKJan Kara <jack@suse.cz>
Date
Nov 18, 2021, 16:49 UTC
Message-ID
<20211118164940.8818-1-jack@suse.cz>
Hello,

In some cases regressions (or generally changes) we are trying to bisect have probabilistic nature. This can for example happen for hard to trigger race condition where it is difficult to distinguish working state from just not hitting the race or it can happen for performance regressions where it is sometimes difficult to distinguish random workload fluctuations from the regression we are looking for. With standard bisection the only option we have is to repeatedly test suggested bisection point until we are sure enough which way to go. This leads to rather long bisection times and still a single wrong decision whether a commit is good to bad renders the whole bisection useless.

Stochastic bisection tries to address these problems. When deciding whether a commit is good or bad, you can also specify your confidence in the decision. For performance tests you can usually directly infer this confidence from the distance of your current result from good/bad values, for hard to reproduce races you are usually 100% confident for bad commits, for good commits you need to somehow estimate your confidence based on past experience with reproducing the issue. The stochastic bisection algorithm then uses these test results and confidences to suggest next commit to try, tracking for each commit the probability the commit is the bad one given current test results. Once some commit reaches high enough probability (set when starting bisection) of being the bad one, we stop bisecting and annouce this commit.

Example:
Consider an example of a stochastic bisection of the following commits:
A--B--C--D-----F-----H--------K
 \     \  \-E-/     /        /
  \     \--------G-/        /
   \------------------I--J-/
And suppose commit I is the bad one. Let's start bisection with:

# We ask bisection for 90% confidence in the identified commit being bad git bisect start --confidence 0.9 %K %A

# Bisection tells us to test %F. Let's assume test went well and we trust # our test results on 70%. So: git bisect good --confidence 0.7

# Bisection tells us to test %H. Again same result: git bisect good --confidence 0.7

# Bisection tells us to test %J. The test should fail for %J (remember %I is # the bad commit) but let's assume the test is falsely positive. So: git bisect good --confidence 0.7

# We are asked to test %H second time. Assume correct result so: git bisect good --confidence 0.7

# We are asked to test %J second time. Assume correct result so: git bisect bad --confidence 0.7

# We are asked to test %J again. Assume correct result so: git bisect bad --confidence 0.7

# And %J once more. Assume false positive so: git bisect good --confidence 0.7

# And %J once more. Assume correct result so: git bisect bad --confidence 0.7

# And %J again. Assume correct result so: git bisect bad --confidence 0.7

# And now we are asked to test %I. Assume correct result so: git bisect bad --confidence 0.7

# We are asked to test %I second time. Assume false positive so: git bisect good --confidence 0.7

# And %I once again. Assume correct result so: git bisect bad --confidence 0.7

# And %I once again. Assume correct result so: git bisect bad --confidence 0.7

# And %I once again. Assume correct result so: git bisect bad --confidence 0.7

And now git tells us %I is the bad commit with desired confidence. We can see the bisection was able to identify the bad commit although there were three false positive tests (out of total 14 tests).

------

This patch set implements stochastic bisection for git. The first part of the series improves some tests so that they accept other valid decisions for bisection points. This is needed because to make it easier to share some logic between normal and stochastic bisection, I needed to slightly change some bits for normal bisection and then since commit weights will be computed in a somewhat different order, also chosen bisection points are sometimes different.

The second part of the series then implements stochastic bisection itself. Note that I didn't integrate any tests for stochastic bisection into 'make test' run yet (so far I did only manual tests) and I still need to update manpages etc. I plan to do that but I've decided to post the series now to get some early feedback.

								Honza
PS: Please leave me in CC for replies. I'm not subscribed to the git mailing
list.
Next: Jan Kara
Message 1 of 43 in “Stochastic bisection support”
  1. Jan KaraNov 18, 2021
  2. 04/27 bisect: Fixup bisect-porcelain/32Jan Kara, Nov 18, 2021
  3. 02/27 bisect: Fixup bisect-porcelain/17Jan Kara, Nov 18, 2021
  4. Taylor BlauNov 18, 2021
  5. Jan KaraNov 22, 2021
  6. 03/27 bisect: Fixup test bisect-porcelain/20Jan Kara, Nov 18, 2021
  7. Chris TorekNov 18, 2021
  8. Taylor BlauNov 18, 2021
  9. Jan KaraNov 22, 2021
  10. 01/27 bisect: Fixup test rev-list-bisect/02Jan Kara, Nov 18, 2021
  11. Chris TorekNov 18, 2021
  12. Johannes SchindelinNov 19, 2021
  13. Jan KaraNov 22, 2021
  14. 10/27 bisect: Fixup bisect-porcelain/58Jan Kara, Nov 18, 2021
  15. 08/27 bisect: Fixup bisect-porcelain/50Jan Kara, Nov 18, 2021
  16. 05/27 bisect: Fixup bisect-porcelain/34Jan Kara, Nov 18, 2021
  17. 09/27 bisect: Fixup bisect-porcelain/54Jan Kara, Nov 18, 2021
  18. 06/27 bisect: Fixup bisect-porcelain/40Jan Kara, Nov 18, 2021
  19. 15/27 bisect: Rename clear_distance() to clear_counted_flag()Jan Kara, Nov 18, 2021
  20. 20/27 bisect: Compute probability a particular commit is badJan Kara, Nov 18, 2021
  21. 23/27 bisect: Find bisection point for stochastic weightsJan Kara, Nov 18, 2021
  22. 11/27 bisect: Fix bisection debuggingJan Kara, Nov 18, 2021
  23. 13/27 bisect: Allow specifying desired result confidenceJan Kara, Nov 18, 2021
  24. 22/27 bisect: Move count_distance()Jan Kara, Nov 18, 2021
  25. 19/27 bisect: Compute reachability of tested revsJan Kara, Nov 18, 2021
  26. 07/27 bisect: Remove duplicated bisect-porcelain/48Jan Kara, Nov 18, 2021
  27. 16/27 bisect: Separate commit list reversalJan Kara, Nov 18, 2021
  28. 14/27 bisect: Use void * for commit_weightJan Kara, Nov 18, 2021
  29. 17/27 bisect: Allow more complex commit weightsJan Kara, Nov 18, 2021
  30. 18/27 bisect: Terminate early if there are no eligible commitsJan Kara, Nov 18, 2021
  31. 21/27 bisect: Reorganize commit weight computationJan Kara, Nov 18, 2021
  32. 12/27 bisect: Accept and store confidence with each decisionJan Kara, Nov 18, 2021
  33. 24/27 bisect: Stop bisection when we are confident about bad commitJan Kara, Nov 18, 2021
  34. 26/27 bisect: Debug stochastic bisectionJan Kara, Nov 18, 2021
  35. 25/27 bisect: Report commit with the highest probabilityJan Kara, Nov 18, 2021
  36. 27/27 bisect: Allow bisection debugging of approx_halfway()Jan Kara, Nov 18, 2021
  37. Taylor BlauNov 18, 2021
  38. Jan KaraNov 22, 2021
  39. Johannes SchindelinNov 19, 2021
  40. Chris TorekNov 20, 2021
  41. Jan KaraNov 22, 2021
  42. Christian CouderNov 22, 2021
  43. Jan KaraNov 22, 2021

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.