- 主题:帮我算个数学题
windows不熟悉，linux下nvme ssd都是Noop调度，也就是来什么实施什么
【 在 zli07 (Anonymous) 的大作中提到: 】
: 因为不可能啊，首先操作系统有缓存的，其次p2p软件即使同时开几十个线程去上传下载，也不可能同时挂起在io，再次即使同时打开几十个文件，文件系统驱动也会把请求排队的
--
FROM 115.171.203.*
就是测的排队的能力
【 在 zli07 (Anonymous) 的大作中提到: 】
: 因为不可能啊，首先操作系统有缓存的，其次p2p软件即使同时开几十个线程去上传下载，也不可能同时挂起在io，再次即使同时打开几十个文件，文件系统驱动也会把请求排队的
--
FROM 113.109.26.*
跳过文件系统直接访问硬件啊，有什么问题么
【 在 siegfried415 的大作中提到: 】
: 那按照你的说法，那测试软件上是如何实现4K/64 thread 测试的？
:
--
FROM 221.219.97.*
那你的意思是，应用程序无法通过OS直接利用ssd的并行读写能力了，是吗？那为什么服务器上的应用就可以通过OS来对ssd进行并行读写？
【 在 zli07 的大作中提到: 】
: 跳过文件系统直接访问硬件啊，有什么问题么
: :
--
修改:siegfried415 FROM 113.232.128.*
FROM 113.232.128.*
我只是说，民用场景4k 64thd没有任何意义。直接的读写ssd，这个场景太少了，再怎么并行读写，接口就一条通道不是么
【 在 siegfried415 的大作中提到: 】
: 那你的意思是，应用程序无法通过OS直接利用ssd的并行读写能力了，是吗？那为什么服务器上的应用就可以通过OS来对ssd进行并行读写？
:
--
FROM 221.219.97.*
你始终没说清楚，民用场景和服务器场景究竟有什么不同，导致了一个利用不了，而另一个就能利用上。这种差别是质上的？还是只是量上的？
【 在 zli07 的大作中提到: 】
: 我只是说，民用场景4k 64thd没有任何意义。直接的读写ssd，这个场景太少了，再怎么并行读写，接口就一条通道不是么
: :
--
FROM 113.232.128.*
服务器场景有更多的CPU核心啊，内核也可以针对性的优化io调度；而且服务器大多数时候做的都是重io轻计算的操作，这也是为什么cpu核心多而频率较低
【 在 siegfried415 的大作中提到: 】
: 你始终没说清楚，民用场景和服务器场景究竟有什么不同，导致了一个利用不了，而另一个就能利用上。这种差别是质上的？还是只是量上的？
:
--
FROM 221.219.97.*
大家最希望听到的就是为什么更多的CPU就可以进行更多的并行读写，因为毕竟SSD的读写控制是由SSD的控制器来构成的，而又不是由CPU来进行的。
【 在 zli07 的大作中提到: 】
: 服务器场景有更多的CPU核心啊，内核也可以针对性的优化io调度；而且服务器大多数时候做的都是重io轻计算的操作，这也是为什么cpu核心多而频率较低
:
: 【 在 siegfried415 的大作中提到: 】
: ...................
--来自微水木3.5.1
--
FROM 175.167.130.*
我没有告诉你说更多的CPU可以进行更多的读写，我只是说4k 64thd对民用场景没有意义，因为根本用不到
【 在 siegfried415 的大作中提到: 】
: 大家最希望听到的就是为什么更多的CPU就可以进行更多的并行读写，因为毕竟SSD的读写控制是由SSD的控制器来构成的，而又不是由CPU来进行的。
--
FROM 221.219.97.*
我经常用beyond compare对比两个目录，这两个目录中可能有几万个甚至几十万个文件，bc能做到在几十秒之内完成几十万个文件的比较，你觉得在这种情况下，操作系统会会不会每秒钟发出成千上万的读写指令？然后这些指令为什么就不能在ssd中被分配到不同的队列中来并行的去执行呢？
类似的操作，还有打包，压缩和解压缩，备份与同步，编译内核，git操作等等，都涉及到大量的小文件的读写，你怎么知道这些操作无法利用ssd的并行读写能力呢？
【 在 zli07 的大作中提到: 】
: 我没有告诉你说更多的CPU可以进行更多的读写，我只是说4k 64thd对民用场景没有意义，因为根本用不到
:
: 【 在 siegfried415 的大作中提到: 】
: ...................
--来自微水木3.5.1
--
修改:siegfried415 FROM 175.167.130.*
FROM 175.167.130.*