2022-08-11 19:23
看评论 好像狠简单的样子
2022-08-08 15:39
api短信验证码有需要的大佬吗?
2022-08-05 09:21
内核镜像大小从 8.5M 增加到 53M,在100MBps带宽下, 以前下载需要1秒的东西,现在需要5秒
2022-08-03 10:28
大厂什么时候能有大厂的担当,就好了,现在的软件广告、弹窗、体积 一个比一个大
2022-08-03 10:26
I am having a hard time seeing how anyone else would want these
2022-08-01 19:51
https://lore.kernel.org/lkml/8735epf7j5.fsf@email.froward.int.ebiederm.org/
2022-08-01 19:50
Is this a tiny embedded device you are taking the timings of?

How are you handling driver shutdown and restart? I would expect those
to be a larger piece of the puzzle than memory.

My desktop can do something like 128GiB/s. Which would suggest that
copying 128MiB of kernel+initrd would take perhaps 10ms. The SHA256
implementation may not be tuned so that could be part of the performance
issue. The SHA256 hash has a reputation for having fast
implementations. I chose SHA256 originally simply because it has more
bits so it makes the odds of detecting an error higher.


If all you care about is booting a kernel as fast as possible it make
make sense to have a large reserved region of memory like we have for
the kexec on panic kernel. If that really makes sense I recommend
adding a second kernel command line option and a reserving second region
of reserved memory. That makes telling if the are any conflicts simple.


I am having a hard time seeing how anyone else would want these
2022-08-01 19:50
看看大神如何回复的:
2022-08-01 15:08
这就是所谓扩大公司影响力;
2022-08-01 10:04
也算是顺应时代,以前没资源,现在便宜了,而且会越来越便宜
2022-07-31 19:02
技术社区的基操就是,看完标题直奔评论区。
2022-07-31 11:01
优秀
2022-07-30 18:22
键来~天不生我李淳罡, 键道万古长如夜!🤣
2022-07-30 11:16
这个所谓的优化,自己家玩玩就好了。Kernel团队才不会收这个玩意儿。
2022-07-30 10:32
liunx 在极致速度上和极致体积上的平衡。 速度大多数场景最重要
2022-07-29 22:51
😂前面的人戾气这么重吗,空间换时间没什么问题,有的人不在乎空间,在乎时间就可以用这个方案,非要什么都整的很高大上吗
2022-07-31 18:55
这群CJ以为 "kexec 快速重启" 是 reboot,所以集体高CHAO了
2022-07-29 21:16
这操作就有点蛋痛了,本来的目的就是减少占用硬盘空间。。。。
2022-07-29 21:01
堪称白痴操作,就为了那么点时间为了他家的宝贝业务,Java 在当今都被玩镜像的人诟病体积大了点,你倒好直接把内核的体积往大的搞,这号人什么时候从字节毕业啊
2022-07-29 20:21
这是什么
2022-07-29 17:40
听着像是加了个 if else
2022-07-29 17:01
我就知道评论区才有真相
2022-07-29 11:41
没啥实际意义,用户根本没感觉,单纯的噱头
2022-07-29 11:36
然后浪费了Linus 500 毫秒的Review时间。
2022-07-29 11:34
应该加个选择,时间优先和空间优先。就像老头环游戏的选项:帧率优先和画质优先。
2022-07-29 11:04
这样实现 “KPI” 有意义吗?
2022-07-29 10:50
以现在的磁盘价格,这几十兆空间确实没有500ms时间值钱
2022-07-28 09:06
听上去高大上,其实是个负优化,本来解压再加载,现在是直接加载,取消解压过程,当然能缩短时间了,但镜像体积增加了6倍,真以为硬盘不要钱是吧,这种优化新手也能做,技术含量很高吗?
2022-08-04 15:28
零散加载效率是很低的,所以肯定有优化
2022-08-12 18:09
做个来看看,linux内核在等你
2022-07-27 10:14
是缩短几秒还是几毫秒?
2022-07-26 14:25
有KPI拿就行。
2022-07-26 14:00
Fxxk you!ByteDance
2022-07-26 13:05
关注后续,会不会竖中指
2022-07-26 11:10
非核心的边角料,是鸡蛋里挑骨头...
2022-07-26 11:02
huangjie.albert (4):
kexec: reuse crash kernel reserved memory for normal kexec
kexec: add CONFING_KEXEC_PURGATORY_SKIP_SIG
x86: Support the uncompressed kernel to speed up booting
x86: boot: avoid memory copy if kernel is uncompressed
2022-07-26 10:59
感觉没啥用,真缺那500ms吗?
2022-07-26 10:56
缩短半秒,镜像增加53M 嗯,牛批!!
2022-07-26 10:26
内核没有配置选项吗,是否启用压缩内核?感觉这个纯属kpi的代码啊
2022-07-26 10:21
先把应用里的垃圾代码整好了再来打系统内核的主意吧。感觉这是为了KPI或者公司宣传来抠系统重启的那么几毫秒
2022-07-26 10:12
别吹了,也不嫌丢人
2022-07-26 08:51
这……半秒是不是可以通过精简其他服务,或者提升硬件配置来实现?
2022-07-26 08:44
其实是去掉了解压过程
2022-07-26 10:24
哈哈哈
2022-08-05 14:16
作为IT技术人员不应该这么肤浅啊,为什么先前要打包加载?搞技术的都知道零散加载效率是很低的,他们这个取消打包后还能提升加载效率那是肯定有优化的,不知道你这哪来这么多赞,都是技术小白吗???
回复 @
{{emojiItem.symbol}}
返回顶部
顶部