Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hostfile: register the removal of an existing key #500

Merged
merged 2 commits into from
Jan 26, 2021
Merged

Hostfile: register the removal of an existing key #500

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
74f9c95
Make sure we register the removal of an existing key
madsbk Jan 25, 2021
9433b79
added tests
madsbk Jan 25, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 4 additions & 0 deletions dask_cuda/device_host_file.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -148,6 +148,10 @@ def __init__(
self.fast = self.host_buffer if memory_limit == 0 else self.host_buffer.fast

def __setitem__(self, key, value):
if key in self.device_buffer:
# Make sure we register the removal of an existing key
del self[key]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure I understand this, what is the case when this is necessary? If the key already exists in self.device_buffer but it now refers to a non-CUDA object that's going to be stored in self.host_buffer, is that right? If so, does this actually happen in practice?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, in the case of DeviceHostFile and in the current Dask/Distributed implementation, I don't think it is likely to happen in practice.
In ProxifyHostFile it is way more likely to happen and I added the check in DeviceHostFile for robustness.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see, thanks for confirming.


if is_device_object(value):
self.device_keys.add(key)
self.device_buffer[key] = value
Expand Down
4 changes: 4 additions & 0 deletions dask_cuda/proxify_host_file.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -183,6 +183,10 @@ def get_access_info(self) -> Tuple[int, List[Tuple[int, int, List[ProxyObject]]]

def __setitem__(self, key, value):
with self.lock:
if key in self.store:
# Make sure we register the removal of an existing key
del self[key]

found_proxies = []
proxied_id_to_proxy = self.proxies_tally.get_proxied_id_to_proxy()
self.store[key] = proxify_device_objects(
Expand Down
5 changes: 5 additions & 0 deletions dask_cuda/tests/test_device_host_file.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -137,6 +137,11 @@ def test_device_host_file_step_by_step(tmp_path):
assert set(dhf.host.keys()) == set()
assert set(dhf.disk.keys()) == set()

dhf["x"] = b
dhf["x"] = a
assert set(dhf.device.keys()) == set()
assert set(dhf.host.keys()) == set(["x"])


@pytest.mark.parametrize("collection", [dict, list, tuple])
@pytest.mark.parametrize("length", [0, 1, 3, 6])
Expand Down
4 changes: 4 additions & 0 deletions dask_cuda/tests/test_proxify_host_file.py
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -59,6 +59,10 @@ def test_one_item_limit():
assert len(p2) == 1
assert p1[0] is p2[0]

# Overwriting "k3" with a non-cuda object, should be noticed
dhf["k3"] = "non-cuda-object"
assert dhf.proxies_tally.get_dev_mem_usage() == 0


@pytest.mark.parametrize("jit_unspill", [True, False])
def test_local_cuda_cluster(jit_unspill):
Expand Down