6 ms·
I use per_process_gpu_memory_fraction extensively [1], but when you are writing code that runs on different GPUs (Titan vs 1080 vs 1070 vs K80) due to change in
by aub3bhat 9y ago
I use per_process_gpu_memory_fraction extensively [1], but when you are writing code that runs on different GPUs (Titan vs 1080 vs 1070 vs K80) due to change in the total memory available you run risk of under allocating or over allocating GPU memory.
[1] https://github.com/AKSHAYUBHAT/DeepVideoAnalytics/blob/master/dvalib/indexer.py#L123 https://github.com/AKSHAYUBHAT/DeepVideoAnalytics/blob/maste...
- jacquesm 9y agoAh yes, I get your problem now, you have to deal with changing environments, not just your own setup to solve a particular problem. I see. That makes it a lot more complicated. Is there a way to fold the pipeline into a single process? Not pretty from a modularity point of view but it just might get the job done.
- aub3bhat 9y agoI am using Celery workers which run a single tensorflow model in solo concurrency mode. The current workaround is to keep track of per process gpu fraction and then incorporate information about Total GPU memory available when assigning workers/celery process to individual GPUs.
- jacquesm 9y agoRight, so essentially you are doing per process memory management because the layers lower down aren't smart enough to handle this transparently. I'm fairly sure that the nvidia libraries do support releasing memory and from what I see on my own machine memory usage of the GPU does go up and down when running longer jobs. So maybe it isn't so much a structural problem as a problem in one particular module that you exercise a lot?