准备了一个 kernel patch, 根据描述猜猜看应该改哪里

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

Distributions

› Ubuntu

› Fedora

› CentOS

中文资源站

› 网易开源镜像站

这是一个创建于 2884 天前的主题，其中的信息可能已经有所发展或是发生改变。

各位新年好.

测试一下某坛目前水平, 希望有人能猜中, 不要让偶太失望.

以下描述适用于最短修改版本, 不写入(修改)现存 struct.
1 使用后会轻微降低 SSD 盘性能(应当无明显感知), 换取同时正在被使用的机械硬盘的提升. 只有单一类型存储设备时无效(请注意下一条).
2 如果机械盘(不论有无 RAID)已经使用了 flashcache / bcache 等 SSD 缓存来加速机械盘, 这种情况无效.

复杂修改版本正在策划中. 也许会在个人认为合适的时间投 LKML. 没有必要立刻就拿这个出名.

ps:
SmartOS 的推荐存储配置是 HDD RAID-Z2 (ZFS) + SSD L2ARC + (可选的 ZIL 设备). 因为这个等同于做了 2 所以对 illumos kernel 来说就没有理由再调查去做同样的补丁了.

SSD

kernel

机械

修改

20 条回复 • 2017-01-02 18:10:42 +08:00

introom

2017-01-01 13:24:00 +08:00 via Android

莫名其妙

edsgerlin

2017-01-01 13:28:36 +08:00

猜是新 I/O scheduler 。

fcicq

2017-01-01 13:36:55 +08:00

@edsgerlin scheduler 的 queue 会落到同一个设备上. 只能管到进程间, 管不到设备间.

crysislinux

2017-01-01 14:52:42 +08:00

"复杂修改版本正在策划中. 也许会在个人认为合适的时间投 LKML. 没有必要立刻就拿这个出名. "

那就准备好了再来。现在这个帖子，我觉得就是想来装个逼

Andiry

2017-01-01 15:19:53 +08:00

根据 per-process 访问的设备不同，分配不同的 IO queue 优先级？ HDD 会有更长的时间片去 issue IO ？

fcicq

2017-01-01 15:30:29 +08:00

@Andiry 设备的特性是不可能用 patch 去改变的, 如果一个请求真的触了盘就是物理问题, 不可能把物理只能输出一定 IOPS 的设备真的在这个层面上加强. 目前的调度器已经考虑了这些因素, 本来不同设备就是不同的 queue.

Andiry

2017-01-01 15:35:55 +08:00

@fcicq 是啊，物理只能输出一定 IOPS 的设备是没法加强的。所以换取同时正在被使用的机械硬盘的提升，到底是怎么个提升法？ bandwidth 提升了多少？需要什么样的 workload ？有没有具体的测试数值？ IO 路径有没有改变？这些不说的话很难猜。

fcicq

2017-01-01 15:37:50 +08:00

@crysislinux 欢迎调查豆瓣日记和 gist (个人不太用 github 本业的 repo 功能), 随便翻翻之后再考虑一下. 比如这篇是不是每个字都认识但都不明白说的啥? ( https://www.douban.com/note/596489332/ )

KIDJourney

2017-01-01 15:39:08 +08:00 via Android

wow ，我给最牛逼的开源项目提了个 patch ，你猜我提了个啥？

对了，我改了下 readme

fcicq

2017-01-01 15:40:53 +08:00

@Andiry 你做一个排除法大概就有明白的希望了, 可以顺便考虑一下为什么会有 2 的情况. 如果过几个小时还想不出来再给你下一个提示 (可以豆油?).

crysislinux

2017-01-01 15:58:32 +08:00

@fcicq 我翻什么翻。

"复杂修改版本正在策划中. 也许会在个人认为合适的时间投 LKML. 没有必要立刻就拿这个出名. "

那就准备好了再来。现在这个帖子，我觉得就是想来装个逼

我回的这个跟你回我的有任何关系吗

fcicq

2017-01-01 16:09:35 +08:00

@crysislinux 看看有没有人能想到一个特定的词. 或者是联系到某篇应该技术世界 50%+ 以上的人都有看过的文章. 如果内核开发者想到了, 就根本轮不到偶去改这个地方, 这才是奇异之处. 如果没有概念, 加一个 sysctl 项也没有人会调.

Andiry

2017-01-01 16:53:20 +08:00

@fcicq 2 是因为 IO 路径变了啊，本来发往 HDD 的 bio 发到 SSD 了。所以屏蔽掉了你的 patch ？

至于技术世界 50% 以上的人都看过的文章，我只能想到谷三篇了。

ryd994

2017-01-01 20:44:30 +08:00 via Android

麻烦 accept 了再来

yangff

2017-01-01 21:09:44 +08:00

同意 @Andiry 在 7L 的观点。

至少拿出，单 SSD 、单 HDD 、 SDD+HDD 在你的 patch 和不带 patch 下的性能差异…… 才有可能做出判断……

只看文章内容，恕我连你的优化是在哪个层面上做出的都无法得出……

yangff

2017-01-01 21:14:21 +08:00

@Andiry 更长的时间 issue IO 应该没有意义。感觉优化不是出在调度上的。考虑修改的量的话…… 某种 trick 达到了等价 cache 的效果？而且应该是在比较高层面上做出的改动…… （如果我对 LZ 不修改 struct 的理解没有错的话）

h4x3rotab

2017-01-02 10:35:25 +08:00 via iPhone

有意思，能探讨一下技术很好啊，楼上那些冷嘲热讽的除了显示出自己档次低真是没别的了

fcicq

2017-01-02 13:27:30 +08:00

@yangff 很多 benchmark 测的明显就是缓存命中率, 然后非命中的代价决定了最终 benchmark 的数值. 仔细考虑一下这句话.

mritd

2017-01-02 17:54:33 +08:00

@h4x3rotab 你看这语气像是讨论技术的么？我个人观点，讨论技术应该是 "各位新年好.准备了一个 kernel patch,使用后会轻微降低 SSD 盘性能(应当无明显感知), 换取同时正在被使用的机械硬盘的提升......大家有什么意见和看法？ "；我认为技术比我叼的很多，但是我从不比我菜的人装逼，因为没意义，更不会哗众取宠的来说什么 "希望 xxxx ，不要让我失望云云的"；@KIDJourney +1

KIDJourney

2017-01-02 18:10:42 +08:00 via Android

@mritd 看了一下楼主的相关文章……感觉中二病爆表。