Systemd-swap: 최대 절전 모드가 정말 불가능합니까?

@TeslaBargain , 일종의 검은 부두 마법.

물론 그것은 당신 스스로 할 수 있습니다-그래서 당신 스스로 할 수 있습니다.

zram의 경우 최대 절전 모드 전에 모든 작업을 수행해야합니다.

1. 새 스왑 파일 추가
2. 포맷 및 스왑 온
3. swapfile의 데이터에 액세스하기위한 모든 정보를 커널 cmdline에 추가합니다 (grub config, systemd-boot, lilo, u-boot 등 변경?)
4. 스왑 아웃 zram
5. 최대 절전 모드 (최대 절전 모드를 가능하게하기 위해 모든 일이 발생하기 전에 얼마나 많은 시간을 잃었는지 모르겠다 고 생각합니다)
6. 재부팅 / 최대 절전 모드 종료 후 모든 작업을 역순으로 수행해야합니다.

그리고 그것은 그러한 종류의 스왑 파일을 지원하는 fs에서만 작동합니다. 즉, 불가능한 btrfs의 경우입니다.

@ Nefelim4ag , 알려 주셔서 감사합니다. 전체적으로 너무 많은 노력을

systemd-swap이 시작될 때 시스템이 사용 가능한 모든 메모리를 최대 절전 모드로 전환 할 수 있도록 충분한 스왑 파일을 포맷 및 스왑하는 옵션이 있다면 어떻게됩니까? 그리고 bootctl 호출을 수행하거나 어떤 종류의 고정 된 위치를 사용하여 테스트를 위해 systemctl-boot 또는 rEFInd 또는 grub 등의 커널 cmdline에 대한 정보를 스왑 파일의 데이터에 액세스 할 수 있습니까?

그런 식으로, 유일한 실제 지연은 zram 사용의 불가피한 부분 인 zram을 교체하는 것입니다.

내가 생각한 것처럼 시작시 스왑을 이미 미리 할당하려는 경우 유용 할만큼 충분히 할당 할 수 있습니다.

안녕하세요. 설치시 스왑 파티션을 정의하고이를 최대 절전 모드에 사용하는 시나리오 (커널이 최대 절전 모드에만 사용하도록 지정하는 방법을 알지 못함) 및 나머지 스왑 작업에 zram을 사용하는 시나리오 (및 이득 공연에서). 고려해야 할 사항입니까? 이견있는 사람?

편집 : https://gist.github.com/klingtnet/c972b8182e4e2818d6d551b0cbeac44b
+ systemd-swap (zram)

시스템적인 최대 절전 모드에 대한 우선 순위 + 후크를 통해이를 달성 할 수 있다고 생각합니다. 다양한 stackoverflow 질문을 빠르게 샅샅이 뒤져도 이에 대한 답이 없었으므로 수동으로 테스트해야했습니다. 이것은 실제로 내가 생각했던 것보다 훨씬 쉬운 수정이므로 5.0 이전에 구현 될 수 있습니다 (전체 수정은 5.0에 있어야 함).

IIRC, 최대 절전 모드에는 단일 스왑 장치가 필요하므로 할당 된 모든 메모리를 RAM / 스왑에 다른 곳에 저장할 수있을만큼 충분히 커야합니까? (그러나 기록되는이 최대 절전 모드 이미지는 기본적으로 약 40 %의 목표로 압축을 사용해야합니다).

직접 시도한 적이 없습니다. 최대 절전 모드는 다른 소프트웨어처럼 할당 된 것처럼 디스크 또는 RAM의 zram 장치에 스왑 파일을 유지하지 않습니까? 메모리가 최대 절전 모드 이미지에 기록되는 한 시스템 상태를 다시 시작하는 중입니다. 새로 부팅하는 것처럼 초기화하는 대신 이전에 할당 된 스왑 장치를 복원 / 재개해야합니까? 따라서 최대 절전 모드 스왑 장치를 토글하는 것 외에 스왑 끄기 / 켜기가 필요하지 않습니까?

단일 스왑 장치 (zswap 또는 zram 없음)로만 최대 절전 모드를 사용했습니다. 이 경우 (두 개 이상의 스왑 장치가있는 것처럼) 디스크 스왑에 어떤 일이 발생하는지 잘 모르겠습니다 (최대 절전 모드 이미지에 맞아야하는 경우 중복 된 것 같습니까?). 마찬가지로 zram에 할당 된 메모리가 있다고 가정합니다. 소프트웨어에 의해 할당 된 다른 메모리와 마찬가지로 최대 절전 모드 이미지에 기록되지만 스왑 부분이 어떻게 처리되는지 확실하지 않습니다. 추가 스왑 장치를 최대 절전 모드 이미지에 기록해야하는 경우에는 zram과 RAM의 zswap 캐시가 압축 해제되고 이력서를 다시 압축해야합니다.

무슨 일이 일어나는지 알기 위해 atm 시나리오를 테스트 할 수 없습니다. VM을 통해 테스트하기가 그리 어렵지 않을까요?

주목할 가치가있는 것은, systemd를 사용하는 대부분의 배포판은 요즘에는 최대 절전 모드를 systemd-sleep hibernate 연기해야합니다. 2019-2020 이후 (v239 + 릴리스에서?)는 커널 매개 변수를 사용하여 대상 스왑 장치 (이 경우에만 iirc)를 지정하지 않고도 최대 절전 모드에서 다시 시작할 수 있으며 암시 적으로 사용할 스왑 장치를 추측합니다. 스왑 파티션이 하나뿐이면 resume (스왑 파일을 사용하는 경우 resume_offset ) 커널 부트 매개 변수를 설정 / 업데이트 할 필요없이 신뢰할 수 있습니다.

다시 말하지만, 아직 확인하기 위해 테스트 한 것이 아닙니다.

업스트림 추적 문제 : https://github.com/systemd/systemd/issues/16708