Skip to content

[SYSTEMDS-2719] Lineage exploitation in buffer pool#1096

Closed
sergred wants to merge 2 commits intoapache:masterfrom
sergred:lineage-exploitation-in-buffer-pool
Closed

[SYSTEMDS-2719] Lineage exploitation in buffer pool#1096
sergred wants to merge 2 commits intoapache:masterfrom
sergred:lineage-exploitation-in-buffer-pool

Conversation

@sergred
Copy link
Copy Markdown
Contributor

@sergred sergred commented Nov 7, 2020

This task introduces a change to object storage mechanisms. For matrices that are results of data generation instructions such as RAND, we store their lineage alongside the data. Under memory pressure, these matrices do not go to the buffer pool. We recompute them from lineage instead of reading evicted buffers from FS. This potentially results in fewer evictions and IO.

… buffer pool.

When buffers are to be evicted, we check if there is a valid lineage item that can be used for further recompute.
In this case, we do not write the buffer to FS and keep the lineage item instead.
The test files are : src/test/java/org/apache/sysds/test/functions/lineage/LineageExploitationBufferPoolTest.java
                     src/test/scripts/functions/lineage/LineageExploitationBufferPool1.dml

The issue is that, so far, all to-be-evicted buffers still go to FS.
… RAND,

we store their lineage alongside the data. Under memory pressure, these matrices
do not go to the buffer pool. We recompute them from lineage instead of reading
evicted buffers from FS. This potentially results in fewer evictions and IO.
@mboehm7
Copy link
Copy Markdown
Contributor

mboehm7 commented Nov 8, 2020

LGTM - thanks @sergred for this great feature. During the merge I just made a few tweaks: added missing license header, fixed wrong formatting (tabs over spaces), changed the way we present the new statistics, fixed the recomputation by lineage, removed an unnecessary ExecutionContext.setVariable (which existed before), and reverted the changes in ByteBuffer as its unrelated to the given feature (the code is still in the PR and we come back once we refactor that).

@asfgit asfgit closed this in f2820a1 Nov 8, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants