虽说目的是提升性能,但感觉为了这个提升(Google 自己的数据都没 10%)修改的代价有点大啊:
考虑下收益,感觉完全看不到能推下去的可能性,哪怕有是 Play 市场来推,要求升级 NDK 可比升级 Target 难多了。
1
seers 67 天前
应该是为了匹配越来越大的 ram ,不然怎么看都像是小马拉大车,只能说战未来了
|
2
kenvix 67 天前 via Android 2
难评,x86 高性能计算这么多年来了还是 4K 页,不知道为什么嵌入式反而这么积极
|
3
billccn 66 天前 3
@seers 应该和内存大小无关,服务器是手机几十倍内存还不都是 4k page 。因为 page table 是多层的,所以可容纳的页面数量一般超过 CPU 的硬件寻址限制。
Android 推这个应该是处于功耗的考虑,因为页面变成 4 倍大,那 page fault 可能就会变成原来的 1/4 概率。另外大多数 Android 设备的 swap 不是硬盘,而是 zRAM ,压缩解压也挺费电的,操作次数越少越好咯。我想 16K 的压缩比可能也比 4K 好一点 |
4
ziseyinzi 66 天前
就是实验性支持一下吧,为 Android 25 做铺垫。
|
5
ysc3839 66 天前 via Android
感觉是跟苹果的风
|
6
imluvian 66 天前 via Android 1
这是给汽车用的。汽车上要开 inline ecc ,能差很多。
|
7
Venjer 66 天前
面向未来,15 也不是强制打开的。开发者模式才能打开,估计至少得 5 年-8 年才能慢慢强制。可以参考 32 位- 64 位 app 的过度时间
|
8
Flyfish233 66 天前 via Android
我有个应用虽然东西多,但是用的都是开源库,自己扒拉扒拉已经可以正常使用 16k page ,有个开发者问我怎么搞不了,我让他发 Libchecker ,一看用了一个华为闭源库。我认为国内会很难推广,而且这个不一定像 64 位这么好推了
|
9
jim9606 OP |
10
V28a19cc 66 天前 1
目前是零收益,因为目前切换 4K/16K 需要格式化 data 。
|
11
Metre 65 天前 1
这几年 arm 的 linux 的 64K page_size 已经把我适配吐了
|
12
GeekGao 65 天前
一方面为了匹配更大的内存需求,另一方面提升内存管理效率:16KB 页面大小比 4KB 大 4 倍, 意味着内存管理单元(MMU)需要处理的页面表项减少了 4 倍,Android 性能和效率方面将会获得显著提升。
|
14
billccn 64 天前 via Android
|