Mark Harris

> > One thing to consider here is that this environment variable currently only affects the Python side. If the app is using RMM from both Python and C++ they...

#1009 is not merged yet, should we just add tests to that PR? > I was going to say "just do what we do for our current tests", but apparently...

Can you just replace `cudf.Buffer` with `rmm.DeviceBuffer`?

> Unfortunately no, because a `cudf.Buffer` could contain arbitrary device memory backed objects underneath it, such as CuPy/Numba arrays, whereas a `rmm.DeviceBuffer` is owning. This sounds like what in C++...

Happy my comment helped kickstart this discussion again! Sounds like there is agreement on a direction forward.

Even if everyone uses RMM, fragmentation is a big problem so having an explicit (possibly expensive) button to push to defragment may be valuable.

On the C++ side, a device_buffer takes an explicit memory resource in any of its methods that allocates memory (e.g. the constructor), and it stores it so that it uses...

Can we make it look like the C++ API (the default value of the optional parameter is a call to `get_current_device_resource`)? That way it's very clear from the interface what...

@shwina should we bump to next release?

@mzient can we close this?