微软打算在为 WSL 提供一个真正的 Linux 内核

2019-05-07 09:30:50 +08:00
 qcts33

https://devblogs.microsoft.com/commandline/shipping-a-linux-kernel-with-windows/

不知道是不是为了提供 Docker 的支持才这么干的,而且 Linux 内核是不是需要用 Hyper-V 的虚拟化啊?

感觉从原来的转译 API 变成基于虚拟机的结构在某种意义上说反而是倒退了……

另外,这个话题应该属于哪个节点啊……

7278 次点击
所在节点    微软
46 条回复
ly50247
2019-05-07 14:12:40 +08:00
@reus 能访问不难,高性能就不容易了。现有虚拟机的共享文件夹性能是比较差的。这个事情主要还是在虚拟机本身做,而不是在内核模块做。按理说以现在 WSL 的基础实现一下并不是很难吧,所以这一点还是比较看好的。
ly50247
2019-05-07 14:29:55 +08:00
@0attocs 我并没有无差别地说 WSL 性能差,但很多性能测试上确实多数项目都是有差距的,比如你发的那个。里边确实有一些占优的,但优势都很小,而其余的基本都差很多。当然可以说主要是 io 性能差导致的,但不能说 io 提升上去后就没有差距了。比如 Windows 下进程启动开销比 Linux 下大基本是常识,自己写个脚本启动一千个 /bin/true 测下时间就知道了,这个和 io 没太大关系了。而编译时要启动大量进程(比如编译 c,一个文件就要启动好几个进程用来预处理、编译、链接等等)。
0attocs
2019-05-07 14:37:14 +08:00
"为什么说是倒退呢?从性能上讲 API 转译并不比虚拟机实现更高(做性能测试的话,很多情况 WSL 要比虚拟机要差,只有一部分会强些),功能上也存在缺陷。"

这是你的原话。误导在于:wsl 不是 api 转译,而是几乎 native,不存在因此产生的性能下降。IO 几乎是性能下降的唯一原因。



“我并没有无差别地说 WSL 性能差,但很多性能测试上确实多数项目都是有差距的,比如你发的那个。里边确实有一些占优的,但优势都很小,而其余的基本都差很多。当然可以说主要是 io 性能差导致的,但不能说 io 提升上去后就没有差距了。比如 Windows 下进程启动开销比 Linux 下大基本是常识,自己写个脚本启动一千个 /bin/true 测下时间就知道了,这个和 io 没太大关系了。而编译时要启动大量进程(比如编译 c,一个文件就要启动好几个进程用来预处理、编译、链接等等)。”

请不要臆测了。仔细阅读下文:
https://blogs.msdn.microsoft.com/wsl/2016/05/23/pico-process-overview/
ly50247
2019-05-07 14:43:39 +08:00
@0attocs WSL 的实现是将 Linux 的 API 转义成 Windows 内核中的现有实现。其余的我想已经说得足够明白了。
0attocs
2019-05-07 15:05:37 +08:00
@ly50247 嗯,你对 wsl 的系列离谱理解和无依据的断言已经错得足够明白了。
xiaoyanbot
2019-05-07 15:07:41 +08:00
去年建的群,来,继续讨论讨论哈:

qq 群 257277694
reus
2019-05-07 15:25:39 +08:00
@ly50247 程序要做 io,当然要通过内核模块。读写文件,就需要先通过实现了该文件系统的内核模块,ext4 / ntfs / btrfs 等等,这些文件系统内核模块又依赖块设备内核模块,例如硬盘、lvm、远程块设备等等。这都是一层层从软件到硬件的。我不知道你说的“这个事情主要还是在虚拟机本身做,而不是在内核模块做”是什么意思。虚拟机虚拟出来的是硬件,要想利用上,必然需要相应的内核模块。

既然 wsl2 打算用虚拟机跑一个 linux 内核而不是兼容层,那实现一个文件系统内核模块,来做和宿主系统的文件系统的互操作,是最自然不过的。
0attocs
2019-05-07 15:51:16 +08:00
@reus
不一样。wsl 首先是在 nt kernel 里实现了 picoprocess 等等 linux kernel 的东西,而不是如 @ly50247 所说的使用“现有实现”。然后在 nt kernel 上实现了和 win32 api 平级的 linux api。
reus
2019-05-07 16:10:59 +08:00
@0attocs 读写 ntfs 也重新实现了?网络栈也重新实现了?
wsl 1 是一个兼容层,可以让 ELF binary 跑在 windows 环境下,picoprocess 是这个兼容层的一部分。进程用了 picoprocess 不代表所有其他东西都不使用现有实现。像网络栈,你不用 nt 现有的,wsl 自己重新实现一个?
wine 也是一样的兼容层,让 PE binary 可以跑在 windows 环境下。它们的原理都是提供 ELF / PE 可以使用的系统调用,所以原理是一样的。
我不知道你说的“转译”是什么意思,wine 并没有将 PE 转成 ELF,wsl 也没有将 ELF 转成 PE,都是实现了一个兼容的环境去让它们运行。
reus
2019-05-07 16:17:42 +08:00
@0attocs s/让 PE binary 可以跑在 windows 环境下 /让 PE binary 可以跑在 linux 环境下

wsl 1 的网络,参考 https://blogs.msdn.microsoft.com/wsl/2016/11/08/225/ ,TCP/IP 栈及往下,都是共用一个实现,这难道不算使用现有实现?

wsl 2 就可以不使用 nt 内核的 TCP/IP 栈而是使用 linux 内核的 TCP/IP 栈,只需要共用链路层或者网卡驱动等。
redsonic
2019-05-07 16:30:50 +08:00
@qcts33 19 楼答案。

@springmarker hyperv 目前无法家用,gpu 很差,有时候客户机的声卡莫名其妙崩溃,merge 数据的时候机器休眠会造成未 merge 的数据丢失,除了 cpu 效率高以外,不比其他家的产品好哪里去。不觉得 WSL2 会吸引跑虚拟机的普通 linux 用户。

既然巨硬造了自己的终端是不是下面要造个 X11 或 wayland 服务器。
qcts33
2019-05-07 16:52:38 +08:00
@reus 转译这个说法是我先开始用的,我所说的转译跟你说的兼容层应该是一个意思。因为按照我的理解,这个兼容层的提供 ELF/PE 调用的方式就是把相应的调用转换或者说转译成底层系统实际支持的调用,从而实现相应的功能。类似于软件工程里所说的适配器模式。
huiyifyj
2019-05-07 16:58:24 +08:00
@rayhy #2
最近好像有消息了。
https://devblogs.microsoft.com/commandline/introducing-windows-terminal/
他们说可以在 windows 商店下载,可能我解锁的姿势不对,没找着,可能要换区,但我不愿捣腾了。
qcts33
2019-05-07 17:01:57 +08:00
@huiyifyj 说了是 This summer in 2019,估计还得一两个月吧
huiyifyj
2019-05-07 17:04:47 +08:00
@qcts33 #34
我看 YouTube 里官方宣传视频下面有评论说商店有下,是不是也不清楚。
mmdsun
2019-05-07 19:39:26 +08:00
只要速度提起来,兼容 vm 我就很满意了
happy123
2019-05-07 22:16:29 +08:00
关于 WSL CPU 性能,我有个实际例子:

我在一台 E5-2620 的机器上跑 pbkdf2,基本上没有 IO 操作,分别在原生 Linux,Windows,WSL 里面测试了 pypy3.5.3, python3.6 下的性能,令我震惊的是,WSL 里面竟然跑赢了原生 Linux 20%!

这不是人品问题,而且是一个单一的加密算法,我在三台机器上测试过,得到的结果都是一样的,所以现在我的一些高计算量的东东,我做到 Python 的 c 扩展里面,用 WSL+pypy 来跑。

至少对我来说,WSL 带来的性能提升好处是实实在在的,很科幻。
happy123
2019-05-07 22:18:10 +08:00
基于以上认识,作为 Pypy 党,我得说 WSL 真香。

WSL2 啥样呢?期盼。
jon
2019-05-07 22:20:26 +08:00
所以用了 wsl2 就不能用 vagrant ?
hljjhb
2019-05-07 22:31:04 +08:00
@happy123 这么科幻的么 Windows 原生跑差距有多大呢

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/561671

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX