Re:A warning about 5.12-rc1
by dspillett on Friday March 05, 2021 @06:36AM
(#26355696)
I assume the argument to be that it adds complexity (out of swap, what do I do, grow it or something else, if set to grow what if there isn't enough space, if set to grow and there are multiple swap locations which do I grow, ...) that needs to be maintained & tested, but isn't commonly enough needed for someone working on the kernel to decide it warrants that effort, given there are workarounds (i.e. dynamically adding swap partitions/volumes/files) for most of the cases where it might be needed.
> I need about 1TB of swap.
I don't think most people[†] would ever want that much to be dynamically allocated. If something has needed that much memory unexpectedly then it is likely to be something like a massive leak or accidental fork bomb. It could quickly get to the point where a performance drop due to swap thrashing means you can't interact with the system to kill the offending process so your system is effectively locked until either hit the BRB or it runs out of the massive maximum storage allocated to swap. Of course that adds more complexity: how do you decide how much too much is? If it is a user decision and you sometimes want it to be able to balloon that much but still want the OOM killer to deal with accidentally leaky processes at other times, then you are back to manually managing swap allocation before/after processes that are expected to heavily use it.
[†] not that it is wrong to have a use case that warrants it, but if there is a safe workaround for such unusual cases that complicates life just a little, then IMO that is preferable to the risk of adding complexity that will likely go relative untested because it isn't commonly used.
> linux
Of course other OSs have made different decisions on the matter, so maybe there is room for further discussion.
> I need about 1TB of swap.
I don't think most people[†] would ever want that much to be dynamically allocated. If something has needed that much memory unexpectedly then it is likely to be something like a massive leak or accidental fork bomb. It could quickly get to the point where a performance drop due to swap thrashing means you can't interact with the system to kill the offending process so your system is effectively locked until either hit the BRB or it runs out of the massive maximum storage allocated to swap. Of course that adds more complexity: how do you decide how much too much is? If it is a user decision and you sometimes want it to be able to balloon that much but still want the OOM killer to deal with accidentally leaky processes at other times, then you are back to manually managing swap allocation before/after processes that are expected to heavily use it.
[†] not that it is wrong to have a use case that warrants it, but if there is a safe workaround for such unusual cases that complicates life just a little, then IMO that is preferable to the risk of adding complexity that will likely go relative untested because it isn't commonly used.
> linux
Of course other OSs have made different decisions on the matter, so maybe there is room for further discussion.