Windows Subsystem for Linux

Архитектурная дилемма: WSL1 против WSL2 — два принципиально разных подхода

Главное техническое отличие WSL от всех существующих альтернатив — наличие двух принципиально разных версий ядра подсистемы. WSL1 использует слой трансляции системных вызовов (lxss.sys и lxcore.sys), работающий в пространстве ядра Windows NT. Этот драйвер перехватывает обращения от скомпилированных ELF-бинарников и конвертирует их в эквивалентные вызовы NT API. По данным Microsoft, совместимость достигает 98% для пользовательских приложений, но критически низка для операций с сетевыми сокетами и inotify. В WSL2 архитектура полностью изменена: используется полноценное ядро Linux 5.10.x, скомпилированное Microsoft под Hyper-V. Это означает 100% совместимость системных вызовов, но вводит накладные расходы на виртуализацию.

Ключевой параметр производительности — задержка при выполнении системных вызовов. В WSL1 трансляция добавляет 0.5–2 микросекунды на вызов (зависит от типа: fork/clone быстрее, mmap — медленнее). В WSL2 задержка составляет 3–8 микросекунд из-за необходимости переключения контекста между виртуальной машиной и хостом. Однако пропускная способность дисковых операций в WSL2 выше на 40–60% благодаря прямому доступу к Devicename через файловую систему ext4 внутри VHDX-образа. Операции чтения/записи внутри /mnt/c в WSL1 ограничены производительством файловой системы DrvFs, которая работает через протокол 9P. Замеры показывают: скорость последовательного чтения через DrvFs в WSL1 составляет 450–520 МБ/с (NVMe SSD), тогда как внутри WSL2 через ext4 — 1800–2100 МБ/с.

Материалы и спецификации: что именно поставляет Microsoft и как это влияет на совместимость

WSL2 поставляется с ядром Linux, скомпилированным из специфического репозитория Microsoft/WSL2-Linux-Kernel. Особенность: в состав включены патчи для интеграции с Hyper-V Lightweight VM (прямая передача прерываний, оптимизированная работа TLB). Версия ядра обновляется автоматически через Windows Update — это отличает WSL от всех сторонних дистрибутивов, где ядро фиксировано. Размер образа rootfs для Ubuntu 24.04 LTS составляет 1.2 ГБ (сжатый) / 3.4 ГБ (развёрнутый). Файловая система — ext4 с включёнными TRIM и inline-атрибутами. Поддержка overlayfs в WSL2 отсутствует на уровне ядра, но реализована через инструменты пользовательского пространства (Distrod, Ubuntu).

Спецификация аппаратных требований для корректной работы WSL2: обязательная поддержка SLAT-трансляции адресов (вторая ступень страничного табличного преобразования) на процессоре Intel (Nehalem и новее) или AMD (Bulldozer и новее). Оперативная память: минимальный пул для фоновых процессов — 512 МБ на изолированную среду, рекомендовано 2–4 ГБ для комфортной работы с компиляторами. При использовании WSL1 эти требования снижаются: достаточно любой x64-архитектуры, даже без VT-x.

Различия от альтернатив: Cygwin, MSYS2, VirtualBox и Docker Desktop

• Тип подсистемы: WSL работает как изолированное окружение с собственным PID-спейсом и сетевым стеком. Cygwin и MSYS2 лишь эмулируют POSIX-интерфейс через DLL-библиотеку cygwin1.dll, что приводит к расхождениям в поведении сигналов и fork(). VirtualBox создаёт полноценную виртуальную машину с отдельным ядром, что даёт максимальную совместимость, но ценой потери доступа к файлам хоста через 9P (задержка доступа к Windows-дискам выше в 2–3 раза по сравнению с WSL2).
• Стек сети и сокеты: WSL1 использует эмуляцию сокетов через Winsock — для приложений это прозрачно, но команды типа iptables, poweroff или модули ядра не работают. WSL2 имеет полноценный сетевой стек Linux, но использует виртуальный коммутатор Hyper-V (vSwitch), что добавляет задержку 0.1–0.3 мс при любом внешнем TCP-соединении. Docker Desktop с бэкендом WSL2 использует именно этот стек, что иногда ведёт к пакетным коллизиям в режиме Bridge. VirtualBox имеет отдельный пользовательский NAT с MTU 1500, что может вызывать фрагментацию при работе с VPN-клиентами.
• Производительность I/O: Скорость работы с файлами внутри дистрибутива (ext4): WSL2 — 1800–2100 МБ/с, WSL1 — 450–520 МБ/с, Docker Desktop (WSL2) — 1500–1700 МБ/с (из-за накладных расходов контейнерной изоляции). Cygwin — скорость ограничена NTFS (обычно 1200–1600 МБ/с, но зависит от драйвера).
• Стандарты совместимости: WSL2 официально сертифицирован для выполнения большинства Unix Benchmarks, включая LMBench и nbench. Cygwin и MSYS2 не проходят тестирование на поведение pthreads и отображение /proc. VirtualBox — полная сертификация для любых дистрибутивов, но требует ручной настройки.
• Управление памятью: WSL2 использует механизм ballooning Hyper-V: память захватывается динамически до предела, установленного в .wslconfig (по умолчанию 50% от доступной ОЗУ хоста, но не менее 8 ГБ). В WSL1 память не выделяется отдельно — все процессы работают в адресном пространстве хоста, что может вызывать нестабильность при утечках (memory leak в WSL не изолирован).
• Уровень отладки: Инструменты perf и kdump в WSL2 работают в ограниченном режиме, так как ядро находится внутри виртуальной машины, доступ к аппаратным регистрам ограничен. Для отладки ядерных паник необходимо подключаться через Hyper-V VMBus — это возможно, но недокументировано. VirtualBox предоставляет полный доступ к ядру через VBoxManage.

Производство и контроль качества: как Microsoft тестирует совместимость WSL

Microsoft использует систему автоматизированного тестирования на базе Azure DevOps: ежедневно запускается более 50 000 тестовых сценариев для WSL, покрывающих 78% системных вызовов Linux 5.10. Тесты включают сценарии LTP (Linux Test Project) — стандартизированный набор для проверки совместимости ядра. По данным отчёта Microsoft (2025), 99.2% тестов LTP проходят успешно на WSL2, что сопоставимо с нативным ядром Ubuntu. Однако 0.8% несоответствий связаны с особенностями работы с таймерами HPET и отсутствием поддержки архитектурных инструкций x86 specific (RDTSCP). Каждая сборка WSL проходит статический анализ кода на предмет соответствия Windows Driver Framework (WDF) — это гарантирует отсутствие прямого доступа к железу, что невозможно обойти. Для сравнения: Cygwin не имеет формального тестирования на уровне ядра, а VirtualBox проходит внутренние тесты Oracle, но они закрыты для публичного аудита.

Особенность WSL — интеграция с Windows Security Center: ядро WSL2 подписано цифровой подписью Microsoft и защищено от загрузки неподписанных модулей. Любые попытки загрузить сторонние LKM (Loadable Kernel Modules) блокируются на уровне Hyper-V. Это повышает стабильность, но исключает использование специализированных драйверов (например, для GPU-вычислений через nvidia.ko без официального драйвера NVIDIA).

Специфические примеры применения WSL в инженерных задачах

Рассмотрим типовую задачу: компиляция кода на C++ с использованием CMake, работа с системой сборки Ninja и тестирование через GoogleTest. В WSL2 время полной пересборки ядра Linux (v6.1, конфигурация defconfig) составляет 720–750 секунд (на AMD Ryzen 9 7950X, 16 ядер). В нативной Ubuntu 24.04 на том же процессоре — 680–700 секунд. Разница в 5–8% обусловлена накладными расходами виртуализации на переключение контекста при планировании потоков. В WSL1 эта задача невыполнима из-за отсутствия поддержки futex и проблем с атомарными операциями на уровне трансляции.

Другой пример — работа с pmap и strace. Команда strace на WSL2 корректно перехватывает все системные вызовы, включая ioctl (для устройств /dev/tty и /dev/random). На WSL1 strace возвращает неполные данные: пропускаются вызовы set_thread_area, что затрудняет отладку многопоточных приложений. Производительность strace на WSL2 — 8200 вызовов в секунду (тестирование с ls -la /usr/bin), что на 15% ниже, чем на нативной системе (9400 вызовов/с).

Специфический сценарий — работа с GPU через CUDA. WSL2 через официальный драйвер NVIDIA (версия 565) обеспечивает доступ к видеокарте через механизм GPU-PV (GPU Partitioning). Производительность в Geekbench 6 CUDA — 92% от нативной производительности на RTX 4090 (при тесте Matrix Multiplication). Для сравнения: VirtualBox с поддержкой VGPU обеспечивает не более 30% производительности. WSL1 вообще не поддерживает GPU-ускорение.

Ограничения и критические замечания: что вы не можете сделать в WSL

• Отсутствие поддержки BPF-хуков: ядро WSL2 скомпилировано без возможности загрузки eBPF-программ пользовательского пространства (патч SECCOMP используется, но eBPF_JIT отключён). Это делает невозможным использование современных инструментов мониторинга вроде bpftrace и solana-validator.
• Фиксированная конфигурация ядра: Microsoft не предоставляет документации по изменению параметров ядра через sysctl_perf. Любые попытки выставить параметр kernel.unprivileged_bpf_disabled блокируются на уровне безопасности Hyper-V.
• Проблемы с реальным временем: таймеры CLOCK_MONOTONIC в WSL2 имеют точность 4 мс (против 1 мс в нативном Linux). Это связано с тем, что виртуальный APIC программируется с частотой 250 Гц (4 мс). Для задач, требующих микросекундной синхронизации (SDR-приёмники, аудиопроцессинг), WSL2 непригоден.
• Ограниченные возможности отладки ядра: использование kdump и crash невозможно из-за отсутствия доступа к физической памяти через /dev/mem (заблокировано Hyper-V).
• Перегрузка при network namespace: WSL2 не поддерживает сетевые пространства имён (netns), что исключает запуск изолированных контейнеров Docker без Docker Desktop. Любые манипуляции с ip netns завершатся ошибкой.

Объективно, WSL2 представляет собой компромиссное решение: оно обеспечивает 95% совместимости с типичными рабочими нагрузками разработчика (компиляция, отладка, работа с git, ssh) за счёт снижения производительности на 5–15% в зависимости от сценария. Для задач, требующих полного контроля над ядром или микросекундной точности, необходимо использовать VirtualBox в режиме полной виртуализации или нативную Linux-машину. Выбор между WSL1 и WSL2 определяется типом приложений: WSL1 предпочтительнее для операций с множеством мелких файлов через DrvFs (скрипты Node.js, Ruby), WSL2 — для тяжелых компиляций и работы с базами данных.

По состоянию на 2026 год, доля разработчиков на Windows, использующих WSL, оценивается в 35% (данные опроса JetBrains). Из них 78% применяют WSL2, 22% — WSL1 или гибридные сценарии. Основные драйверы внедрения — необходимость совместимости с CI/CD пайплайнами и поддержка AI/ML инструментария (PyTorch, TensorFlow), которые не имеют стабильной версии под нативный Windows. Заводские тесты Microsoft для каждой сборки WSL гарантируют 99.2% прохождение LTP, что является самым высоким показателем среди всех коммерческих реализаций Linux-подсистем под Windows.

Добавлено: 23.04.2026