2020-03-30 03:31:24 +03:00
|
|
|
#include "git-compat-util.h"
|
|
|
|
#include "bloom.h"
|
2020-03-30 03:31:26 +03:00
|
|
|
#include "diff.h"
|
|
|
|
#include "diffcore.h"
|
|
|
|
#include "revision.h"
|
|
|
|
#include "hashmap.h"
|
2020-04-06 19:59:50 +03:00
|
|
|
#include "commit-graph.h"
|
|
|
|
#include "commit.h"
|
2020-03-30 03:31:26 +03:00
|
|
|
|
|
|
|
define_commit_slab(bloom_filter_slab, struct bloom_filter);
|
|
|
|
|
2020-05-08 02:51:02 +03:00
|
|
|
static struct bloom_filter_slab bloom_filters;
|
2020-03-30 03:31:26 +03:00
|
|
|
|
|
|
|
struct pathmap_hash_entry {
|
|
|
|
struct hashmap_entry entry;
|
|
|
|
const char path[FLEX_ARRAY];
|
|
|
|
};
|
2020-03-30 03:31:24 +03:00
|
|
|
|
|
|
|
static uint32_t rotate_left(uint32_t value, int32_t count)
|
|
|
|
{
|
|
|
|
uint32_t mask = 8 * sizeof(uint32_t) - 1;
|
|
|
|
count &= mask;
|
|
|
|
return ((value << count) | (value >> ((-count) & mask)));
|
|
|
|
}
|
|
|
|
|
bloom.c: introduce core Bloom filter constructs
Introduce the constructs for Bloom filters, Bloom filter keys
and Bloom filter settings.
For details on what Bloom filters are and how they work, refer
to Dr. Derrick Stolee's blog post [1]. It provides a concise
explanation of the adoption of Bloom filters as described in
[2] and [3].
Implementation specifics:
1. We currently use 7 and 10 for the number of hashes and the
size of each entry respectively. They served as great starting
values, the mathematical details behind this choice are
described in [1] and [4]. The implementation, while not
completely open to it at the moment, is flexible enough to allow
for tweaking these settings in the future.
Note: The performance gains we have observed with these values
are significant enough that we did not need to tweak these
settings. The performance numbers are included in the cover letter
of this series and in the commit message of the subsequent commit
where we use Bloom filters to speed up `git log -- path`.
2. As described in [1] and [3], we do not need 7 independent hashing
functions. We use the Murmur3 hashing scheme, seed it twice and
then combine those to procure an arbitrary number of hash values.
3. The filters will be sized according to the number of changes in
each commit, in multiples of 8 bit words.
[1] Derrick Stolee
"Supercharging the Git Commit Graph IV: Bloom Filters"
https://devblogs.microsoft.com/devops/super-charging-the-git-commit-graph-iv-Bloom-filters/
[2] Flavio Bonomi, Michael Mitzenmacher, Rina Panigrahy, Sushil Singh, George Varghese
"An Improved Construction for Counting Bloom Filters"
http://theory.stanford.edu/~rinap/papers/esa2006b.pdf
https://doi.org/10.1007/11841036_61
[3] Peter C. Dillinger and Panagiotis Manolios
"Bloom Filters in Probabilistic Verification"
http://www.ccs.neu.edu/home/pete/pub/Bloom-filters-verification.pdf
https://doi.org/10.1007/978-3-540-30494-4_26
[4] Thomas Mueller Graf, Daniel Lemire
"Xor Filters: Faster and Smaller Than Bloom and Cuckoo Filters"
https://arxiv.org/abs/1912.08258
Helped-by: Derrick Stolee <dstolee@microsoft.com>
Reviewed-by: Jakub Narębski <jnareb@gmail.com>
Signed-off-by: Garima Singh <garima.singh@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-30 03:31:25 +03:00
|
|
|
static inline unsigned char get_bitmask(uint32_t pos)
|
|
|
|
{
|
|
|
|
return ((unsigned char)1) << (pos & (BITS_PER_WORD - 1));
|
|
|
|
}
|
|
|
|
|
2020-04-06 19:59:50 +03:00
|
|
|
static int load_bloom_filter_from_graph(struct commit_graph *g,
|
2020-05-01 18:30:18 +03:00
|
|
|
struct bloom_filter *filter,
|
|
|
|
struct commit *c)
|
2020-04-06 19:59:50 +03:00
|
|
|
{
|
|
|
|
uint32_t lex_pos, start_index, end_index;
|
2020-06-17 12:14:11 +03:00
|
|
|
uint32_t graph_pos = commit_graph_position(c);
|
2020-04-06 19:59:50 +03:00
|
|
|
|
2020-06-17 12:14:11 +03:00
|
|
|
while (graph_pos < g->num_commits_in_base)
|
2020-04-06 19:59:50 +03:00
|
|
|
g = g->base_graph;
|
|
|
|
|
commit-graph: introduce 'get_bloom_filter_settings()'
Many places in the code often need a pointer to the commit-graph's
'struct bloom_filter_settings', in which case they often take the value
from the top-most commit-graph.
In the non-split case, this works as expected. In the split case,
however, things get a little tricky. Not all layers in a chain of
incremental commit-graphs are required to themselves have Bloom data,
and so whether or not some part of the code uses Bloom filters depends
entirely on whether or not the top-most level of the commit-graph chain
has Bloom filters.
This has been the behavior since Bloom filters were introduced, and has
been codified into the tests since a759bfa9ee (t4216: add end to end
tests for git log with Bloom filters, 2020-04-06). In fact, t4216.130
requires that Bloom filters are not used in exactly the case described
earlier.
There is no reason that this needs to be the case, since it is perfectly
valid for commits in an earlier layer to have Bloom filters when commits
in a newer layer do not.
Since Bloom settings are guaranteed in practice to be the same for any
layer in a chain that has Bloom data, it is sufficient to traverse the
'->base_graph' pointer until either (1) a non-null 'struct
bloom_filter_settings *' is found, or (2) until we are at the root of
the commit-graph chain.
Introduce a 'get_bloom_filter_settings()' function that does just this,
and use it instead of purely dereferencing the top-most graph's
'->bloom_filter_settings' pointer.
While we're at it, add an additional test in t5324 to guard against code
in the commit-graph writing machinery that doesn't correctly handle a
NULL 'struct bloom_filter *'.
Co-authored-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-09 18:22:44 +03:00
|
|
|
/* The commit graph commit 'c' lives in doesn't carry Bloom filters. */
|
2020-04-06 19:59:50 +03:00
|
|
|
if (!g->chunk_bloom_indexes)
|
|
|
|
return 0;
|
|
|
|
|
2020-06-17 12:14:11 +03:00
|
|
|
lex_pos = graph_pos - g->num_commits_in_base;
|
2020-04-06 19:59:50 +03:00
|
|
|
|
|
|
|
end_index = get_be32(g->chunk_bloom_indexes + 4 * lex_pos);
|
|
|
|
|
|
|
|
if (lex_pos > 0)
|
|
|
|
start_index = get_be32(g->chunk_bloom_indexes + 4 * (lex_pos - 1));
|
|
|
|
else
|
|
|
|
start_index = 0;
|
|
|
|
|
|
|
|
filter->len = end_index - start_index;
|
|
|
|
filter->data = (unsigned char *)(g->chunk_bloom_data +
|
|
|
|
sizeof(unsigned char) * start_index +
|
|
|
|
BLOOMDATA_CHUNK_HEADER_SIZE);
|
|
|
|
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2020-03-30 03:31:24 +03:00
|
|
|
/*
|
|
|
|
* Calculate the murmur3 32-bit hash value for the given data
|
|
|
|
* using the given seed.
|
|
|
|
* Produces a uniformly distributed hash value.
|
|
|
|
* Not considered to be cryptographically secure.
|
|
|
|
* Implemented as described in https://en.wikipedia.org/wiki/MurmurHash#Algorithm
|
|
|
|
*/
|
|
|
|
uint32_t murmur3_seeded(uint32_t seed, const char *data, size_t len)
|
|
|
|
{
|
|
|
|
const uint32_t c1 = 0xcc9e2d51;
|
|
|
|
const uint32_t c2 = 0x1b873593;
|
|
|
|
const uint32_t r1 = 15;
|
|
|
|
const uint32_t r2 = 13;
|
|
|
|
const uint32_t m = 5;
|
|
|
|
const uint32_t n = 0xe6546b64;
|
|
|
|
int i;
|
|
|
|
uint32_t k1 = 0;
|
|
|
|
const char *tail;
|
|
|
|
|
|
|
|
int len4 = len / sizeof(uint32_t);
|
|
|
|
|
|
|
|
uint32_t k;
|
|
|
|
for (i = 0; i < len4; i++) {
|
|
|
|
uint32_t byte1 = (uint32_t)data[4*i];
|
|
|
|
uint32_t byte2 = ((uint32_t)data[4*i + 1]) << 8;
|
|
|
|
uint32_t byte3 = ((uint32_t)data[4*i + 2]) << 16;
|
|
|
|
uint32_t byte4 = ((uint32_t)data[4*i + 3]) << 24;
|
|
|
|
k = byte1 | byte2 | byte3 | byte4;
|
|
|
|
k *= c1;
|
|
|
|
k = rotate_left(k, r1);
|
|
|
|
k *= c2;
|
|
|
|
|
|
|
|
seed ^= k;
|
|
|
|
seed = rotate_left(seed, r2) * m + n;
|
|
|
|
}
|
|
|
|
|
|
|
|
tail = (data + len4 * sizeof(uint32_t));
|
|
|
|
|
|
|
|
switch (len & (sizeof(uint32_t) - 1)) {
|
|
|
|
case 3:
|
|
|
|
k1 ^= ((uint32_t)tail[2]) << 16;
|
|
|
|
/*-fallthrough*/
|
|
|
|
case 2:
|
|
|
|
k1 ^= ((uint32_t)tail[1]) << 8;
|
|
|
|
/*-fallthrough*/
|
|
|
|
case 1:
|
|
|
|
k1 ^= ((uint32_t)tail[0]) << 0;
|
|
|
|
k1 *= c1;
|
|
|
|
k1 = rotate_left(k1, r1);
|
|
|
|
k1 *= c2;
|
|
|
|
seed ^= k1;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
seed ^= (uint32_t)len;
|
|
|
|
seed ^= (seed >> 16);
|
|
|
|
seed *= 0x85ebca6b;
|
|
|
|
seed ^= (seed >> 13);
|
|
|
|
seed *= 0xc2b2ae35;
|
|
|
|
seed ^= (seed >> 16);
|
|
|
|
|
|
|
|
return seed;
|
bloom.c: introduce core Bloom filter constructs
Introduce the constructs for Bloom filters, Bloom filter keys
and Bloom filter settings.
For details on what Bloom filters are and how they work, refer
to Dr. Derrick Stolee's blog post [1]. It provides a concise
explanation of the adoption of Bloom filters as described in
[2] and [3].
Implementation specifics:
1. We currently use 7 and 10 for the number of hashes and the
size of each entry respectively. They served as great starting
values, the mathematical details behind this choice are
described in [1] and [4]. The implementation, while not
completely open to it at the moment, is flexible enough to allow
for tweaking these settings in the future.
Note: The performance gains we have observed with these values
are significant enough that we did not need to tweak these
settings. The performance numbers are included in the cover letter
of this series and in the commit message of the subsequent commit
where we use Bloom filters to speed up `git log -- path`.
2. As described in [1] and [3], we do not need 7 independent hashing
functions. We use the Murmur3 hashing scheme, seed it twice and
then combine those to procure an arbitrary number of hash values.
3. The filters will be sized according to the number of changes in
each commit, in multiples of 8 bit words.
[1] Derrick Stolee
"Supercharging the Git Commit Graph IV: Bloom Filters"
https://devblogs.microsoft.com/devops/super-charging-the-git-commit-graph-iv-Bloom-filters/
[2] Flavio Bonomi, Michael Mitzenmacher, Rina Panigrahy, Sushil Singh, George Varghese
"An Improved Construction for Counting Bloom Filters"
http://theory.stanford.edu/~rinap/papers/esa2006b.pdf
https://doi.org/10.1007/11841036_61
[3] Peter C. Dillinger and Panagiotis Manolios
"Bloom Filters in Probabilistic Verification"
http://www.ccs.neu.edu/home/pete/pub/Bloom-filters-verification.pdf
https://doi.org/10.1007/978-3-540-30494-4_26
[4] Thomas Mueller Graf, Daniel Lemire
"Xor Filters: Faster and Smaller Than Bloom and Cuckoo Filters"
https://arxiv.org/abs/1912.08258
Helped-by: Derrick Stolee <dstolee@microsoft.com>
Reviewed-by: Jakub Narębski <jnareb@gmail.com>
Signed-off-by: Garima Singh <garima.singh@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-30 03:31:25 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
void fill_bloom_key(const char *data,
|
2020-05-01 18:30:18 +03:00
|
|
|
size_t len,
|
|
|
|
struct bloom_key *key,
|
|
|
|
const struct bloom_filter_settings *settings)
|
bloom.c: introduce core Bloom filter constructs
Introduce the constructs for Bloom filters, Bloom filter keys
and Bloom filter settings.
For details on what Bloom filters are and how they work, refer
to Dr. Derrick Stolee's blog post [1]. It provides a concise
explanation of the adoption of Bloom filters as described in
[2] and [3].
Implementation specifics:
1. We currently use 7 and 10 for the number of hashes and the
size of each entry respectively. They served as great starting
values, the mathematical details behind this choice are
described in [1] and [4]. The implementation, while not
completely open to it at the moment, is flexible enough to allow
for tweaking these settings in the future.
Note: The performance gains we have observed with these values
are significant enough that we did not need to tweak these
settings. The performance numbers are included in the cover letter
of this series and in the commit message of the subsequent commit
where we use Bloom filters to speed up `git log -- path`.
2. As described in [1] and [3], we do not need 7 independent hashing
functions. We use the Murmur3 hashing scheme, seed it twice and
then combine those to procure an arbitrary number of hash values.
3. The filters will be sized according to the number of changes in
each commit, in multiples of 8 bit words.
[1] Derrick Stolee
"Supercharging the Git Commit Graph IV: Bloom Filters"
https://devblogs.microsoft.com/devops/super-charging-the-git-commit-graph-iv-Bloom-filters/
[2] Flavio Bonomi, Michael Mitzenmacher, Rina Panigrahy, Sushil Singh, George Varghese
"An Improved Construction for Counting Bloom Filters"
http://theory.stanford.edu/~rinap/papers/esa2006b.pdf
https://doi.org/10.1007/11841036_61
[3] Peter C. Dillinger and Panagiotis Manolios
"Bloom Filters in Probabilistic Verification"
http://www.ccs.neu.edu/home/pete/pub/Bloom-filters-verification.pdf
https://doi.org/10.1007/978-3-540-30494-4_26
[4] Thomas Mueller Graf, Daniel Lemire
"Xor Filters: Faster and Smaller Than Bloom and Cuckoo Filters"
https://arxiv.org/abs/1912.08258
Helped-by: Derrick Stolee <dstolee@microsoft.com>
Reviewed-by: Jakub Narębski <jnareb@gmail.com>
Signed-off-by: Garima Singh <garima.singh@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-30 03:31:25 +03:00
|
|
|
{
|
|
|
|
int i;
|
|
|
|
const uint32_t seed0 = 0x293ae76f;
|
|
|
|
const uint32_t seed1 = 0x7e646e2c;
|
|
|
|
const uint32_t hash0 = murmur3_seeded(seed0, data, len);
|
|
|
|
const uint32_t hash1 = murmur3_seeded(seed1, data, len);
|
|
|
|
|
|
|
|
key->hashes = (uint32_t *)xcalloc(settings->num_hashes, sizeof(uint32_t));
|
|
|
|
for (i = 0; i < settings->num_hashes; i++)
|
|
|
|
key->hashes[i] = hash0 + i * hash1;
|
|
|
|
}
|
|
|
|
|
line-log: integrate with changed-path Bloom filters
The previous changes to the line-log machinery focused on making the
first result appear faster. This was achieved by no longer walking the
entire commit history before returning the early results. There is still
another way to improve the performance: walk most commits much faster.
Let's use the changed-path Bloom filters to reduce time spent computing
diffs.
Since the line-log computation requires opening blobs and checking the
content-diff, there is still a lot of necessary computation that cannot
be replaced with changed-path Bloom filters. The part that we can reduce
is most effective when checking the history of a file that is deep in
several directories and those directories are modified frequently. In
this case, the computation to check if a commit is TREESAME to its first
parent takes a large fraction of the time. That is ripe for improvement
with changed-path Bloom filters.
We must ensure that prepare_to_use_bloom_filters() is called in
revision.c so that the bloom_filter_settings are loaded into the struct
rev_info from the commit-graph. Of course, some cases are still
forbidden, but in the line-log case the pathspec is provided in a
different way than normal.
Since multiple paths and segments could be requested, we compute the
struct bloom_key data dynamically during the commit walk. This could
likely be improved, but adds code complexity that is not valuable at
this time.
There are two cases to care about: merge commits and "ordinary" commits.
Merge commits have multiple parents, but if we are TREESAME to our first
parent in every range, then pass the blame for all ranges to the first
parent. Ordinary commits have the same condition, but each is done
slightly differently in the process_ranges_[merge|ordinary]_commit()
methods. By checking if the changed-path Bloom filter can guarantee
TREESAME, we can avoid that tree-diff cost. If the filter says "probably
changed", then we need to run the tree-diff and then the blob-diff if
there was a real edit.
The Linux kernel repository is a good testing ground for the performance
improvements claimed here. There are two different cases to test. The
first is the "entire history" case, where we output the entire history
to /dev/null to see how long it would take to compute the full line-log
history. The second is the "first result" case, where we find how long
it takes to show the first value, which is an indicator of how quickly a
user would see responses when waiting at a terminal.
To test, I selected the paths that were changed most frequently in the
top 10,000 commits using this command (stolen from StackOverflow [1]):
git log --pretty=format: --name-only -n 10000 | sort | \
uniq -c | sort -rg | head -10
which results in
121 MAINTAINERS
63 fs/namei.c
60 arch/x86/kvm/cpuid.c
59 fs/io_uring.c
58 arch/x86/kvm/vmx/vmx.c
51 arch/x86/kvm/x86.c
45 arch/x86/kvm/svm.c
42 fs/btrfs/disk-io.c
42 Documentation/scsi/index.rst
(along with a bogus first result). It appears that the path
arch/x86/kvm/svm.c was renamed, so we ignore that entry. This leaves the
following results for the real command time:
| | Entire History | First Result |
| Path | Before | After | Before | After |
|------------------------------|--------|--------|--------|--------|
| MAINTAINERS | 4.26 s | 3.87 s | 0.41 s | 0.39 s |
| fs/namei.c | 1.99 s | 0.99 s | 0.42 s | 0.21 s |
| arch/x86/kvm/cpuid.c | 5.28 s | 1.12 s | 0.16 s | 0.09 s |
| fs/io_uring.c | 4.34 s | 0.99 s | 0.94 s | 0.27 s |
| arch/x86/kvm/vmx/vmx.c | 5.01 s | 1.34 s | 0.21 s | 0.12 s |
| arch/x86/kvm/x86.c | 2.24 s | 1.18 s | 0.21 s | 0.14 s |
| fs/btrfs/disk-io.c | 1.82 s | 1.01 s | 0.06 s | 0.05 s |
| Documentation/scsi/index.rst | 3.30 s | 0.89 s | 1.46 s | 0.03 s |
It is worth noting that the least speedup comes for the MAINTAINERS file
which is
* edited frequently,
* low in the directory heirarchy, and
* quite a large file.
All of those points lead to spending more time doing the blob diff and
less time doing the tree diff. Still, we see some improvement in that
case and significant improvement in other cases. A 2-4x speedup is
likely the more typical case as opposed to the small 5% change for that
file.
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-11 14:56:19 +03:00
|
|
|
void clear_bloom_key(struct bloom_key *key)
|
|
|
|
{
|
|
|
|
FREE_AND_NULL(key->hashes);
|
|
|
|
}
|
|
|
|
|
bloom.c: introduce core Bloom filter constructs
Introduce the constructs for Bloom filters, Bloom filter keys
and Bloom filter settings.
For details on what Bloom filters are and how they work, refer
to Dr. Derrick Stolee's blog post [1]. It provides a concise
explanation of the adoption of Bloom filters as described in
[2] and [3].
Implementation specifics:
1. We currently use 7 and 10 for the number of hashes and the
size of each entry respectively. They served as great starting
values, the mathematical details behind this choice are
described in [1] and [4]. The implementation, while not
completely open to it at the moment, is flexible enough to allow
for tweaking these settings in the future.
Note: The performance gains we have observed with these values
are significant enough that we did not need to tweak these
settings. The performance numbers are included in the cover letter
of this series and in the commit message of the subsequent commit
where we use Bloom filters to speed up `git log -- path`.
2. As described in [1] and [3], we do not need 7 independent hashing
functions. We use the Murmur3 hashing scheme, seed it twice and
then combine those to procure an arbitrary number of hash values.
3. The filters will be sized according to the number of changes in
each commit, in multiples of 8 bit words.
[1] Derrick Stolee
"Supercharging the Git Commit Graph IV: Bloom Filters"
https://devblogs.microsoft.com/devops/super-charging-the-git-commit-graph-iv-Bloom-filters/
[2] Flavio Bonomi, Michael Mitzenmacher, Rina Panigrahy, Sushil Singh, George Varghese
"An Improved Construction for Counting Bloom Filters"
http://theory.stanford.edu/~rinap/papers/esa2006b.pdf
https://doi.org/10.1007/11841036_61
[3] Peter C. Dillinger and Panagiotis Manolios
"Bloom Filters in Probabilistic Verification"
http://www.ccs.neu.edu/home/pete/pub/Bloom-filters-verification.pdf
https://doi.org/10.1007/978-3-540-30494-4_26
[4] Thomas Mueller Graf, Daniel Lemire
"Xor Filters: Faster and Smaller Than Bloom and Cuckoo Filters"
https://arxiv.org/abs/1912.08258
Helped-by: Derrick Stolee <dstolee@microsoft.com>
Reviewed-by: Jakub Narębski <jnareb@gmail.com>
Signed-off-by: Garima Singh <garima.singh@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-30 03:31:25 +03:00
|
|
|
void add_key_to_filter(const struct bloom_key *key,
|
2020-05-01 18:30:18 +03:00
|
|
|
struct bloom_filter *filter,
|
|
|
|
const struct bloom_filter_settings *settings)
|
bloom.c: introduce core Bloom filter constructs
Introduce the constructs for Bloom filters, Bloom filter keys
and Bloom filter settings.
For details on what Bloom filters are and how they work, refer
to Dr. Derrick Stolee's blog post [1]. It provides a concise
explanation of the adoption of Bloom filters as described in
[2] and [3].
Implementation specifics:
1. We currently use 7 and 10 for the number of hashes and the
size of each entry respectively. They served as great starting
values, the mathematical details behind this choice are
described in [1] and [4]. The implementation, while not
completely open to it at the moment, is flexible enough to allow
for tweaking these settings in the future.
Note: The performance gains we have observed with these values
are significant enough that we did not need to tweak these
settings. The performance numbers are included in the cover letter
of this series and in the commit message of the subsequent commit
where we use Bloom filters to speed up `git log -- path`.
2. As described in [1] and [3], we do not need 7 independent hashing
functions. We use the Murmur3 hashing scheme, seed it twice and
then combine those to procure an arbitrary number of hash values.
3. The filters will be sized according to the number of changes in
each commit, in multiples of 8 bit words.
[1] Derrick Stolee
"Supercharging the Git Commit Graph IV: Bloom Filters"
https://devblogs.microsoft.com/devops/super-charging-the-git-commit-graph-iv-Bloom-filters/
[2] Flavio Bonomi, Michael Mitzenmacher, Rina Panigrahy, Sushil Singh, George Varghese
"An Improved Construction for Counting Bloom Filters"
http://theory.stanford.edu/~rinap/papers/esa2006b.pdf
https://doi.org/10.1007/11841036_61
[3] Peter C. Dillinger and Panagiotis Manolios
"Bloom Filters in Probabilistic Verification"
http://www.ccs.neu.edu/home/pete/pub/Bloom-filters-verification.pdf
https://doi.org/10.1007/978-3-540-30494-4_26
[4] Thomas Mueller Graf, Daniel Lemire
"Xor Filters: Faster and Smaller Than Bloom and Cuckoo Filters"
https://arxiv.org/abs/1912.08258
Helped-by: Derrick Stolee <dstolee@microsoft.com>
Reviewed-by: Jakub Narębski <jnareb@gmail.com>
Signed-off-by: Garima Singh <garima.singh@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-03-30 03:31:25 +03:00
|
|
|
{
|
|
|
|
int i;
|
|
|
|
uint64_t mod = filter->len * BITS_PER_WORD;
|
|
|
|
|
|
|
|
for (i = 0; i < settings->num_hashes; i++) {
|
|
|
|
uint64_t hash_mod = key->hashes[i] % mod;
|
|
|
|
uint64_t block_pos = hash_mod / BITS_PER_WORD;
|
|
|
|
|
|
|
|
filter->data[block_pos] |= get_bitmask(hash_mod);
|
|
|
|
}
|
|
|
|
}
|
2020-03-30 03:31:26 +03:00
|
|
|
|
|
|
|
void init_bloom_filters(void)
|
|
|
|
{
|
|
|
|
init_bloom_filter_slab(&bloom_filters);
|
|
|
|
}
|
|
|
|
|
2020-05-11 14:56:12 +03:00
|
|
|
static int pathmap_cmp(const void *hashmap_cmp_fn_data,
|
|
|
|
const struct hashmap_entry *eptr,
|
|
|
|
const struct hashmap_entry *entry_or_key,
|
|
|
|
const void *keydata)
|
|
|
|
{
|
|
|
|
const struct pathmap_hash_entry *e1, *e2;
|
|
|
|
|
|
|
|
e1 = container_of(eptr, const struct pathmap_hash_entry, entry);
|
|
|
|
e2 = container_of(entry_or_key, const struct pathmap_hash_entry, entry);
|
|
|
|
|
|
|
|
return strcmp(e1->path, e2->path);
|
|
|
|
}
|
|
|
|
|
bloom: split 'get_bloom_filter()' in two
'get_bloom_filter' takes a flag to control whether it will compute a
Bloom filter if the requested one is missing. In the next patch, we'll
add yet another parameter to this method, which would force all but one
caller to specify an extra 'NULL' parameter at the end.
Instead of doing this, split 'get_bloom_filter' into two functions:
'get_bloom_filter' and 'get_or_compute_bloom_filter'. The former only
looks up a Bloom filter (and does not compute one if it's missing,
thus dropping the 'compute_if_not_present' flag). The latter does
compute missing Bloom filters, with an additional parameter to store
whether or not it needed to do so.
This simplifies many call-sites, since the majority of existing callers
to 'get_bloom_filter' do not want missing Bloom filters to be computed
(so they can drop the parameter entirely and use the simpler version of
the function).
While we're at it, instrument the new 'get_or_compute_bloom_filter()'
with counters in the 'write_commit_graph_context' struct which store
the number of filters that we did and didn't compute, as well as filters
that were truncated.
It would be nice to drop the 'compute_if_not_present' flag entirely,
since all remaining callers of 'get_or_compute_bloom_filter' pass it as
'1', but this will change in a future patch and hence cannot be removed.
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-16 21:07:32 +03:00
|
|
|
struct bloom_filter *get_or_compute_bloom_filter(struct repository *r,
|
|
|
|
struct commit *c,
|
|
|
|
int compute_if_not_present,
|
|
|
|
enum bloom_filter_computed *computed)
|
2020-03-30 03:31:26 +03:00
|
|
|
{
|
|
|
|
struct bloom_filter *filter;
|
|
|
|
struct bloom_filter_settings settings = DEFAULT_BLOOM_FILTER_SETTINGS;
|
|
|
|
int i;
|
|
|
|
struct diff_options diffopt;
|
2020-03-30 03:31:27 +03:00
|
|
|
int max_changes = 512;
|
2020-03-30 03:31:26 +03:00
|
|
|
|
bloom: split 'get_bloom_filter()' in two
'get_bloom_filter' takes a flag to control whether it will compute a
Bloom filter if the requested one is missing. In the next patch, we'll
add yet another parameter to this method, which would force all but one
caller to specify an extra 'NULL' parameter at the end.
Instead of doing this, split 'get_bloom_filter' into two functions:
'get_bloom_filter' and 'get_or_compute_bloom_filter'. The former only
looks up a Bloom filter (and does not compute one if it's missing,
thus dropping the 'compute_if_not_present' flag). The latter does
compute missing Bloom filters, with an additional parameter to store
whether or not it needed to do so.
This simplifies many call-sites, since the majority of existing callers
to 'get_bloom_filter' do not want missing Bloom filters to be computed
(so they can drop the parameter entirely and use the simpler version of
the function).
While we're at it, instrument the new 'get_or_compute_bloom_filter()'
with counters in the 'write_commit_graph_context' struct which store
the number of filters that we did and didn't compute, as well as filters
that were truncated.
It would be nice to drop the 'compute_if_not_present' flag entirely,
since all remaining callers of 'get_or_compute_bloom_filter' pass it as
'1', but this will change in a future patch and hence cannot be removed.
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-16 21:07:32 +03:00
|
|
|
if (computed)
|
|
|
|
*computed = BLOOM_NOT_COMPUTED;
|
|
|
|
|
2020-07-01 16:27:23 +03:00
|
|
|
if (!bloom_filters.slab_size)
|
2020-03-30 03:31:26 +03:00
|
|
|
return NULL;
|
|
|
|
|
|
|
|
filter = bloom_filter_slab_at(&bloom_filters, c);
|
|
|
|
|
2020-04-06 19:59:50 +03:00
|
|
|
if (!filter->data) {
|
|
|
|
load_commit_graph_info(r, c);
|
2020-06-17 12:14:10 +03:00
|
|
|
if (commit_graph_position(c) != COMMIT_NOT_FROM_GRAPH &&
|
commit-graph: introduce 'get_bloom_filter_settings()'
Many places in the code often need a pointer to the commit-graph's
'struct bloom_filter_settings', in which case they often take the value
from the top-most commit-graph.
In the non-split case, this works as expected. In the split case,
however, things get a little tricky. Not all layers in a chain of
incremental commit-graphs are required to themselves have Bloom data,
and so whether or not some part of the code uses Bloom filters depends
entirely on whether or not the top-most level of the commit-graph chain
has Bloom filters.
This has been the behavior since Bloom filters were introduced, and has
been codified into the tests since a759bfa9ee (t4216: add end to end
tests for git log with Bloom filters, 2020-04-06). In fact, t4216.130
requires that Bloom filters are not used in exactly the case described
earlier.
There is no reason that this needs to be the case, since it is perfectly
valid for commits in an earlier layer to have Bloom filters when commits
in a newer layer do not.
Since Bloom settings are guaranteed in practice to be the same for any
layer in a chain that has Bloom data, it is sufficient to traverse the
'->base_graph' pointer until either (1) a non-null 'struct
bloom_filter_settings *' is found, or (2) until we are at the root of
the commit-graph chain.
Introduce a 'get_bloom_filter_settings()' function that does just this,
and use it instead of purely dereferencing the top-most graph's
'->bloom_filter_settings' pointer.
While we're at it, add an additional test in t5324 to guard against code
in the commit-graph writing machinery that doesn't correctly handle a
NULL 'struct bloom_filter *'.
Co-authored-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-09 18:22:44 +03:00
|
|
|
load_bloom_filter_from_graph(r->objects->commit_graph, filter, c))
|
|
|
|
return filter;
|
2020-04-06 19:59:50 +03:00
|
|
|
}
|
|
|
|
|
2020-07-01 16:27:23 +03:00
|
|
|
if (filter->data)
|
2020-04-06 19:59:50 +03:00
|
|
|
return filter;
|
2020-07-01 16:27:23 +03:00
|
|
|
if (!compute_if_not_present)
|
|
|
|
return NULL;
|
2020-04-06 19:59:50 +03:00
|
|
|
|
2020-03-30 03:31:26 +03:00
|
|
|
repo_diff_setup(r, &diffopt);
|
|
|
|
diffopt.flags.recursive = 1;
|
2020-04-09 16:00:11 +03:00
|
|
|
diffopt.detect_rename = 0;
|
2020-03-30 03:31:27 +03:00
|
|
|
diffopt.max_changes = max_changes;
|
2020-03-30 03:31:26 +03:00
|
|
|
diff_setup_done(&diffopt);
|
|
|
|
|
2020-05-11 14:56:10 +03:00
|
|
|
/* ensure commit is parsed so we have parent information */
|
|
|
|
repo_parse_commit(r, c);
|
|
|
|
|
2020-03-30 03:31:26 +03:00
|
|
|
if (c->parents)
|
|
|
|
diff_tree_oid(&c->parents->item->object.oid, &c->object.oid, "", &diffopt);
|
|
|
|
else
|
|
|
|
diff_tree_oid(NULL, &c->object.oid, "", &diffopt);
|
|
|
|
diffcore_std(&diffopt);
|
|
|
|
|
bloom: use num_changes not nr for limit detection
As diff_tree_oid() computes a diff, it will terminate early if the
total number of changed paths is strictly larger than max_changes.
This includes the directories that changed, not just the file paths.
However, only the file paths are reflected in the resulting diff
queue's "nr" value.
Use the "num_changes" from diffopt to check if the diff terminated
early. This is incredibly important, as it can result in incorrect
filters! For example, the first commit in the Linux kernel repo
reports only 471 changes, but since these are nested inside several
directories they expand to 513 "real" changes, and in fact the
total list of changes is not reported. Thus, the computed filter
for this commit is incorrect.
Demonstrate the subtle difference by using one fewer file change
in the 'get bloom filter for commit with 513 changes' test. Before,
this edited 513 files inside "bigDir" which hit this inequality.
However, dropping the file count by one demonstrates how the
previous inequality was incorrect but the new one is correct.
Signed-off-by: Derrick Stolee <dstolee@microsoft.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-11 14:56:13 +03:00
|
|
|
if (diffopt.num_changes <= max_changes) {
|
2020-03-30 03:31:26 +03:00
|
|
|
struct hashmap pathmap;
|
|
|
|
struct pathmap_hash_entry *e;
|
|
|
|
struct hashmap_iter iter;
|
2020-05-11 14:56:12 +03:00
|
|
|
hashmap_init(&pathmap, pathmap_cmp, NULL, 0);
|
2020-03-30 03:31:26 +03:00
|
|
|
|
|
|
|
for (i = 0; i < diff_queued_diff.nr; i++) {
|
|
|
|
const char *path = diff_queued_diff.queue[i]->two->path;
|
|
|
|
|
|
|
|
/*
|
2020-05-11 14:56:12 +03:00
|
|
|
* Add each leading directory of the changed file, i.e. for
|
|
|
|
* 'dir/subdir/file' add 'dir' and 'dir/subdir' as well, so
|
|
|
|
* the Bloom filter could be used to speed up commands like
|
|
|
|
* 'git log dir/subdir', too.
|
|
|
|
*
|
|
|
|
* Note that directories are added without the trailing '/'.
|
|
|
|
*/
|
2020-03-30 03:31:26 +03:00
|
|
|
do {
|
|
|
|
char *last_slash = strrchr(path, '/');
|
|
|
|
|
|
|
|
FLEX_ALLOC_STR(e, path, path);
|
|
|
|
hashmap_entry_init(&e->entry, strhash(path));
|
2020-05-11 14:56:12 +03:00
|
|
|
|
|
|
|
if (!hashmap_get(&pathmap, &e->entry, NULL))
|
|
|
|
hashmap_add(&pathmap, &e->entry);
|
|
|
|
else
|
|
|
|
free(e);
|
2020-03-30 03:31:26 +03:00
|
|
|
|
|
|
|
if (!last_slash)
|
|
|
|
last_slash = (char*)path;
|
|
|
|
*last_slash = '\0';
|
|
|
|
|
|
|
|
} while (*path);
|
|
|
|
|
|
|
|
diff_free_filepair(diff_queued_diff.queue[i]);
|
|
|
|
}
|
|
|
|
|
|
|
|
filter->len = (hashmap_get_size(&pathmap) * settings.bits_per_entry + BITS_PER_WORD - 1) / BITS_PER_WORD;
|
|
|
|
filter->data = xcalloc(filter->len, sizeof(unsigned char));
|
|
|
|
|
|
|
|
hashmap_for_each_entry(&pathmap, &iter, e, entry) {
|
|
|
|
struct bloom_key key;
|
|
|
|
fill_bloom_key(e->path, strlen(e->path), &key, &settings);
|
|
|
|
add_key_to_filter(&key, filter, &settings);
|
|
|
|
}
|
|
|
|
|
|
|
|
hashmap_free_entries(&pathmap, struct pathmap_hash_entry, entry);
|
|
|
|
} else {
|
|
|
|
for (i = 0; i < diff_queued_diff.nr; i++)
|
|
|
|
diff_free_filepair(diff_queued_diff.queue[i]);
|
|
|
|
filter->data = NULL;
|
|
|
|
filter->len = 0;
|
bloom: split 'get_bloom_filter()' in two
'get_bloom_filter' takes a flag to control whether it will compute a
Bloom filter if the requested one is missing. In the next patch, we'll
add yet another parameter to this method, which would force all but one
caller to specify an extra 'NULL' parameter at the end.
Instead of doing this, split 'get_bloom_filter' into two functions:
'get_bloom_filter' and 'get_or_compute_bloom_filter'. The former only
looks up a Bloom filter (and does not compute one if it's missing,
thus dropping the 'compute_if_not_present' flag). The latter does
compute missing Bloom filters, with an additional parameter to store
whether or not it needed to do so.
This simplifies many call-sites, since the majority of existing callers
to 'get_bloom_filter' do not want missing Bloom filters to be computed
(so they can drop the parameter entirely and use the simpler version of
the function).
While we're at it, instrument the new 'get_or_compute_bloom_filter()'
with counters in the 'write_commit_graph_context' struct which store
the number of filters that we did and didn't compute, as well as filters
that were truncated.
It would be nice to drop the 'compute_if_not_present' flag entirely,
since all remaining callers of 'get_or_compute_bloom_filter' pass it as
'1', but this will change in a future patch and hence cannot be removed.
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-16 21:07:32 +03:00
|
|
|
|
|
|
|
if (computed)
|
|
|
|
*computed |= BLOOM_TRUNC_LARGE;
|
2020-03-30 03:31:26 +03:00
|
|
|
}
|
|
|
|
|
bloom: split 'get_bloom_filter()' in two
'get_bloom_filter' takes a flag to control whether it will compute a
Bloom filter if the requested one is missing. In the next patch, we'll
add yet another parameter to this method, which would force all but one
caller to specify an extra 'NULL' parameter at the end.
Instead of doing this, split 'get_bloom_filter' into two functions:
'get_bloom_filter' and 'get_or_compute_bloom_filter'. The former only
looks up a Bloom filter (and does not compute one if it's missing,
thus dropping the 'compute_if_not_present' flag). The latter does
compute missing Bloom filters, with an additional parameter to store
whether or not it needed to do so.
This simplifies many call-sites, since the majority of existing callers
to 'get_bloom_filter' do not want missing Bloom filters to be computed
(so they can drop the parameter entirely and use the simpler version of
the function).
While we're at it, instrument the new 'get_or_compute_bloom_filter()'
with counters in the 'write_commit_graph_context' struct which store
the number of filters that we did and didn't compute, as well as filters
that were truncated.
It would be nice to drop the 'compute_if_not_present' flag entirely,
since all remaining callers of 'get_or_compute_bloom_filter' pass it as
'1', but this will change in a future patch and hence cannot be removed.
Signed-off-by: Taylor Blau <me@ttaylorr.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-16 21:07:32 +03:00
|
|
|
if (computed)
|
|
|
|
*computed |= BLOOM_COMPUTED;
|
|
|
|
|
2020-03-30 03:31:26 +03:00
|
|
|
free(diff_queued_diff.queue);
|
|
|
|
DIFF_QUEUE_CLEAR(&diff_queued_diff);
|
|
|
|
|
|
|
|
return filter;
|
|
|
|
}
|
2020-04-06 19:59:52 +03:00
|
|
|
|
|
|
|
int bloom_filter_contains(const struct bloom_filter *filter,
|
|
|
|
const struct bloom_key *key,
|
|
|
|
const struct bloom_filter_settings *settings)
|
|
|
|
{
|
|
|
|
int i;
|
|
|
|
uint64_t mod = filter->len * BITS_PER_WORD;
|
|
|
|
|
|
|
|
if (!mod)
|
|
|
|
return -1;
|
|
|
|
|
|
|
|
for (i = 0; i < settings->num_hashes; i++) {
|
|
|
|
uint64_t hash_mod = key->hashes[i] % mod;
|
|
|
|
uint64_t block_pos = hash_mod / BITS_PER_WORD;
|
|
|
|
if (!(filter->data[block_pos] & get_bitmask(hash_mod)))
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 1;
|
2020-05-08 02:51:02 +03:00
|
|
|
}
|