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

2017-01-01 13:16:53 +08:00
 fcicq
各位新年好.

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

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

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

ps:
SmartOS 的推荐存储配置是 HDD RAID-Z2 (ZFS) + SSD L2ARC + (可选的 ZIL 设备). 因为这个等同于做了 2 所以对 illumos kernel 来说就没有理由再调查去做同样的补丁了.
4055 次点击
所在节点    Linux
20 条回复
introom
2017-01-01 13:24:00 +08:00
莫名其妙
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
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
麻烦 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
有意思,能探讨一下技术很好啊,楼上那些冷嘲热讽的除了显示出自己档次低真是没别的了
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
@mritd 看了一下楼主的相关文章……感觉中二病爆表。

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

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

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

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

© 2021 V2EX