> Ну обойти проблему так можно, но это ж костыль. Не должна система
> при свапе замирать напрочь.А вот это - не факт. Когда код программы выдавливается в своп, когда выполнение доходит до выдавленной в своп страницы - выполнение программы нафиг клинится. До тех пор пока ядро не достанет нужную страницу из свопа. Если в своп улетело много - скорость выполнения программы провалится в полный унитаз, т.к. скорость механического диска vs скорость RAM это как скорость самоката vs скорость ракеты. В зависимости от того что это была за программа - результат может и не понравиться.
А если при этом еще и накопитель один на все, да еще и механический - он будет жестоко seek'ать, сильно просадив скорость всех остальных операций. Так что остальные запросы на работу с файлами которые ранее отрабатывали быстро, станут медленными и печальными. Так что пока тормозной ноутбучный накопитель свои патефонные головы гонит добрых 50 миллисекунд с другого края диска - вы как-нибудь его подождете, потому что чудес - не бывает. А потом окажется что через 4 кило кода надо еще раз так же. И еще. Логично что работать будет "не очень". Т.к. и файловые операции на системного накопителе просели и программы тормозят.
И, кстати, таким макаром можно практически любую систему при желании ушатать. Своп, особенно на тормозном накопителе, особенно если это единственный системный диск - потенциально позволяет довольно сильно угробить интерактивность, особенно если винч механический. Разумными настройками свопления можно минимизировать вред, но то что HDD это очень медленный эмулятор оперативы и просадка неизбежна - это факт. Самый лучший вариант - добавить оперативы до состояния когда ее всегда хватает и выключить своп совсем. Интерактивность взлетит до небес и метода ее просадить не будет чисто технически.