Return to Answer

It seems that after a day of inactivity the kernel believes the entire GUI is no longer needed and wipes it from RAM (swaps it to disk).

The kernel is doing The Right Thing™ believing it. Why would it keep in RAM unused¹ memory and so essentially waste it instead of using it as cache or something?

I don't think the Linux kernel is gratuitously or anticipatory swapping out pages so if it does it, that must be to store something else on RAM, thus improving performance of your long running task, or at least with this goal.

If you know when you'll need to reuse your laptop in advance, you might use the at command (or crontab) to schedule a swap cleanup (swapoff -a;swapon -a).

As cleaning the swap might be overkill, and even trigger the OOM killer if for some reason, not everything fit in RAM, you might just "unswap"² everything related to the running applications you want to revive.

One way to do it would be to attach a debugger like gdb to each of the affected processes and trigger a core dump generation:

# gdb -p <pid>
...
generate-core-dump /dev/null
...
quit

As you wrote your long running application is not reusing the data it reads after the initial pass, so you are in a specific cas where long term caching is not useful. Then bypassing the cache by using direct i/o like suggested by Will Crawford should be a good workaround.

Alternatively, you might just regularly flush the file cache by echoing 1 or 3 to the /proc/sys/vm/drop_caches pseudo-file before the OS thinks it's a good idea to swap out your GUI apps and environment.

See How do you empty the buffers and cache on a Linux system? for details.

¹_{Unused in the sense: no more actively used since a significant period of time, the memory still being relevant to its owners.}
  ²_{Put back in RAM pages stored on the swap area.}

It seems that after a day of inactivity the kernel believes the entire GUI is no longer needed and wipes it from RAM (swaps it to disk).

The kernel is doing The Right Thing™ believing it. Why would it keep unused¹ memory in RAM and so essentially waste it instead of using it as cache or something?

I don't think the Linux kernel is gratuitously or anticipatory swapping out pages, so if it does it that must be to store something else on RAM, thus improving performance of your long running task, or at least with this goal.

If you know when you'll need to reuse your laptop in advance, you might use the at command (or crontab) to schedule a swap cleanup (swapoff -a;swapon -a).

As cleaning the swap might be overkill, and even trigger the OOM killer if for some reason, not everything fit in RAM, you might just "unswap"² everything related to the running applications you want to revive.

One way to do it would be to attach a debugger like gdb to each of the affected processes and trigger a core dump generation:

# gdb -p <pid>
...
generate-core-dump /dev/null
...
quit

As you wrote, your long running application is not reusing the data it reads after the initial pass, so you are in a specific case where long term caching is not useful. Then bypassing the cache by using direct I/O like suggested by Will Crawford should be a good workaround.

Alternatively, you might just regularly flush the file cache by echoing 1 or 3 to the /proc/sys/vm/drop_caches pseudo-file before the OS thinks it's a good idea to swap out your GUI applications and environment.

See How do you empty the buffers and cache on a Linux system? for details.

¹_{Unused in the sense: no more actively used since a significant period of time, the memory still being relevant to its owners.} 
²_{Put back in RAM pages stored on the swap area.}

It seems that after a day of inactivity the kernel believes the entire GUI is no longer needed and wipes it from RAM (swaps it to disk).

The kernel is doing The Right Thing™ believing it. Why would it keep in RAM unused memory and so essentially waste it instead of using it as cache or something?

I don't think the Linux kernel is gratuitously or anticipatory swapping out pages so if it does it, that must be to store something else on RAM, thus improving performance of your long running task.

If you know when you'll need to reuse your laptop in advance, you might use the at command (or crontab) to schedule a swap cleanup (swapoff -a;swapon -a).

As cleaning the swap might be overkill, and even trigger the OOM killer if for some reason, not everything fit in RAM, you might just "unswap"¹ everything related to the running applications you want to revive.

One way to do it would be to attach a debugger like gdb to each of the affected processes and trigger a core dump generation:

# gdb -p <pid>
...
generate-core-dump /dev/null
...
quit

As you wrote your long running application is not reusing the data it reads after the initial pass, so you are in a specific cas where long term caching is not useful. Then bypassing the cache by using direct i/o like suggested by Will Crawford should be a good workaround.

Alternatively, you might just regularly flush the file cache by echoing 1 or 3 to the /proc/sys/vm/drop_caches pseudo-file before the OS thinks it's a good idea to swap out your GUI apps and environment.

See How do you empty the buffers and cache on a Linux system? for details.

¹_{Put back in RAM pages stored on the swap area}

It seems that after a day of inactivity the kernel believes the entire GUI is no longer needed and wipes it from RAM (swaps it to disk).

The kernel is doing The Right Thing™ believing it. Why would it keep in RAM unused¹ memory and so essentially waste it instead of using it as cache or something?

I don't think the Linux kernel is gratuitously or anticipatory swapping out pages so if it does it, that must be to store something else on RAM, thus improving performance of your long running task, or at least with this goal.

If you know when you'll need to reuse your laptop in advance, you might use the at command (or crontab) to schedule a swap cleanup (swapoff -a;swapon -a).

As cleaning the swap might be overkill, and even trigger the OOM killer if for some reason, not everything fit in RAM, you might just "unswap"² everything related to the running applications you want to revive.

One way to do it would be to attach a debugger like gdb to each of the affected processes and trigger a core dump generation:

# gdb -p <pid>
...
generate-core-dump /dev/null
...
quit

As you wrote your long running application is not reusing the data it reads after the initial pass, so you are in a specific cas where long term caching is not useful. Then bypassing the cache by using direct i/o like suggested by Will Crawford should be a good workaround.

Alternatively, you might just regularly flush the file cache by echoing 1 or 3 to the /proc/sys/vm/drop_caches pseudo-file before the OS thinks it's a good idea to swap out your GUI apps and environment.

See How do you empty the buffers and cache on a Linux system? for details.

¹_{Unused in the sense: no more actively used since a significant period of time, the memory still being relevant to its owners.}
²_{Put back in RAM pages stored on the swap area.}

It seems that after a day of inactivity the kernel believes the entire GUI is no longer needed and wipes it from RAM (swaps it to disk).

The kernel is doing The Right Thing™ believing it. Why would it keep in RAM unused memory and so essentially waste it instead of using it as cache or something?

I don't think the Linux kernel is gratuitously or anticipatory swapping out pages so if it does it, that must be to store something else on RAM, thus improving performance of your long running task.

If you know when you'll need to reuse your laptop in advance, you might use the at command (or crontab) to schedule a swap cleanup (swapoff -a;swapon -a).

As cleaning the swap might be overkill, and even trigger the OOM killer if for some reason, not everything fit in RAM, you might just "unswap"¹ everything related to the running applications you want to revive.

One way to do it would be to attach a debugger like gdb to each of the affected processes and trigger a core dump generation:

# gdb -p <pid>
...
generate-core-dump /dev/null
...
quit

¹_{Put back in RAM pages stored on the swap area}

It seems that after a day of inactivity the kernel believes the entire GUI is no longer needed and wipes it from RAM (swaps it to disk).

The kernel is doing The Right Thing™ believing it. Why would it keep in RAM unused memory and so essentially waste it instead of using it as cache or something?

I don't think the Linux kernel is gratuitously or anticipatory swapping out pages so if it does it, that must be to store something else on RAM, thus improving performance of your long running task.

If you know when you'll need to reuse your laptop in advance, you might use the at command (or crontab) to schedule a swap cleanup (swapoff -a;swapon -a).

As cleaning the swap might be overkill, and even trigger the OOM killer if for some reason, not everything fit in RAM, you might just "unswap"¹ everything related to the running applications you want to revive.

One way to do it would be to attach a debugger like gdb to each of the affected processes and trigger a core dump generation:

# gdb -p <pid>
...
generate-core-dump /dev/null
...
quit

As you wrote your long running application is not reusing the data it reads after the initial pass, so you are in a specific cas where long term caching is not useful. Then bypassing the cache by using direct i/o like suggested by Will Crawford should be a good workaround.

Alternatively, you might just regularly flush the file cache by echoing 1 or 3 to the /proc/sys/vm/drop_caches pseudo-file before the OS thinks it's a good idea to swap out your GUI apps and environment.

See How do you empty the buffers and cache on a Linux system? for details.

¹_{Put back in RAM pages stored on the swap area}