On Tue 30-01-18 10:00:07, Christian KÃnig wrote:
Am 30.01.2018 um 08:55 schrieb Michal Hocko:How does that help when the rest of the system might eat swap?
On Tue 30-01-18 02:56:51, He, Roger wrote:For graphics and compute applications on GPUs it isn't unusual to use large
Hi Michal:Why do you so much memory? Are you going to use TB of memory on large
We need a API to tell TTM module the system totally has how many swap
cache. Then TTM module can use it to restrict how many the swap cache
it can use to prevent triggering OOM. For Now we set the threshold of
swap size TTM used as 1/2 * total size and leave the rest for others
use.
systems? What about memory hotplug when the memory is added/released?
amounts of system memory.
Our standard policy in TTM is to allow 50% of system memory to be pinned for
use with GPUs (the hardware can't do page faults).
When that limit is exceeded (or the shrinker callbacks tell us to make room)
we wait for any GPU work to finish and copy buffer content into a shmem
file.
This copy into a shmem file can easily trigger the OOM killer if there isn't
any swap space left and that is something we want to avoid.
So what we want to do is to apply this 50% rule to swap space as well and
deny allocation of buffer objects when it is exceeded.
Could you be more specific? What kind of buffer objects you have inWhy? That is pretty much exactly what we are doing with buffer objects andBut get_nr_swap_pages is the only API we can accessed from otherExactly. Your scaling configuration based on get_nr_swap_pages or the
module now. It can't cover the case of the dynamic swap size
increment. I mean: user can use "swapon" to enable new swap file or
swap disk dynamically or "swapoff" to disable swap space.
available memory simply sounds wrong.
system memory for years.
mind?