On Mon, Dec 15, 2014 at 05:36:25PM -0700, Dann Frazier wrote:
>
> There's the question of whether or not we would be penalizing the
> performance of other classes of workloads people want to run on arm64.
> If there are some representative tests we should be looking at, please
> let me know.
So, this is the obvious concern, and it only makes logical sense that
many workloads will perform better with a smaller page size, as if you
don't actually need the giant loads, you'll be flushing fewer caches
for nothing. But, I'll put my money where my mouth is and see if I can
find benchmarks to back up that hand-waving.
> I'm not sure how much interest there is for ARMv7 compat in Ubuntu.
> There is the developer use case of using the same hardware for armhf
> and arm64 porting - which, theoretically, we could also achieve by
> rebuilding those ports w/ an updated binutils. But otherwise, I'm not
> aware of many legacy ARMv7 apps that users are likely to want to bring
> over to Ubuntu/arm64 that couldn't be rebuilt.
So, retroactively rebuilding all our already released dists is clearly
not an option, and I hadn't even thought about this armv7 compat issue.
This does impact our previous master plan for scrapping our armv7 build
infrastructure and building armhf on arm64 in chroots, like we do for
all our other 64/32 port pairs.
Now, if qemu-system-arm --enable-kvm happens to work on arm64 (with 64k
pages), this might be a non-issue, as we can run fully accelerated v7
VMs on our v8 kit, and that would serve just as well as 32-on-64 with
chroots. Is that possible? Does it work today? If not, is there any
one working on making it work?
... Adam
--
ubuntu-devel mailing list
ubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
