커널 매개변수를 쉽게 변경 sysctl한 다음 이를 영구적으로 만들 수 있습니다./etc/sysctl.d하지만 기본값과 같은 기본 커널 매개변수를 변경하는 빠른 방법이 있습니까?VM 전환 가능성 = 60커널 컴파일 단계 중.
커널 소스 코드에 다음과 같은 내용이 있다는 것을 발견했습니다.mm/vmscan.c다음을 포함하는 파일:
(...)
int vm_swappiness = 60
(...)
매개변수는 많은 소스 파일에 존재하는 이러한 매개변수를 수정하고 변경하는 올바른 방법입니까, 아니면 변경하려는 일부 사용자 파일을 생성하는 것이 가능한가요? 모듈도 마찬가지입니다. 내 모듈에 다음과 같은 옵션을 추가/변경하려면 모듈 소스 파일을 편집해야 합니까?/etc/modprobe.d:
options modulename parameter=value
요약하자면, 컴파일 단계에서 일부 커널 기본 매개변수와 일부 모듈 옵션을 변경하고 싶습니다.
답변1
sysctl 설정을 통해 실제로 조정할 수 있는 커널 매개변수에 대해, 커널 소스 코드를 패치하여 이러한 값을 수정하는 데 거의 관심이 없습니다.
다음 커널 업데이트에서 작업을 다시 실행해야 하며, 패치를 수행하는 경우 패치가 올바르게 적용되었는지 확인해야 합니다.지나침실제로는 몇 가지 다른 기본값을 설정하는 것뿐입니다!
사용자 공간에 절대 노출되지 않는 하드코딩된 값에 대해, 일반적으로 이를 수정하는 데 관심이 없거나 위험이 높다고 가정할 수 있습니다. 이에 의존하는 다른 모든 매개변수에 미치는 영향을 자세히 조사할 필요는 없습니다. 가능합니까? 관련 커널 소스 코드에 적극적으로 기여하는 사람이 아니라면 다음과 같이 말하고 싶습니다.아니요!
그러나 사용자 공간에 반드시 노출되지 않는 커널 조정 가능 항목의 경우 그렇게 하는 데 관심이 있을 수 있습니다.커널 구성 옵션에 따라 다릅니다.
스케줄러 조정 가능 항목을 예로 들어 보겠습니다.sched_latency_nsCONFIG_SCHED_DEBUG가 설정된 경우에만 사용자 공간에 노출됩니다.
이 구성 설정을 사용하면 오버헤드가 발생합니다.
따라서 대기 시간을 줄이고 스케줄러 처리 시 오버헤드를 수용하려는 것은 논리적으로 일관성이 없습니다.
매우 특정한 경우에는 디버깅 코드를 비활성화하고 값을 하드코딩하는 것이 데이터를 변경하는 유일한 방법이 되기 때문에 일관되게 보일 수 있습니다.
물론 이런 방식으로 작업을 수행하면 커널이 아직 테스트하지 않은 값을 강제로 적용하고 잠재적으로 해당 값을 깨뜨려 디버깅을 방해할 가능성이 있다는 것을 알고 있습니다. (위의 예와 관련하여...실제로 다음과 같이 플레이하면 불쾌한 결과를 얻을 수 있습니다.sched_wakeup_grinderity_ns값. )
물론 다음에 커널을 업데이트할 때에는 모든 작업을 다시 실행해야 한다는 점, 커널 변경 시 설정이 미치는 영향을 이해해야 한다는 점, 즉 커널에 대해 매우 깊이 이해해야 한다는 점을 알고 있으며, 최소한 변경 로그를 주의 깊게 읽으십시오.
그래서,"커널 매개변수를 수정하는 것이 맞나요?"? 내가 말할 것…전용 커널 디버깅 기능이 지원하는 전용 sysctl 방식을 통해 설정된 튜너블을 사용하기 전에 실제로 시스템을 광범위하게 테스트하지 않은 한, 아니요! 당연히 아니지!심지어 Linus 자신도 그렇게 하지 않을 것입니다.
그 외에도 개인적인 경험으로 볼 때 스케줄러 튜너블(디버깅 코드 및 기타 통계 비활성화)과 관련하여 준수한 방식으로 인해 객관적으로 확인하거나 관련성을 확인하는 데 사용할 수 있는 데이터가 0개라는 것을 인정해야 합니다. 내 장난을…