From: voidlinux-github@inbox.vuxu.org
To: ml@inbox.vuxu.org
Subject: Re: linux4.19/5.1/5.2: build with ELFv2 ABI on ppc64 big endian
Date: Sat, 13 Jul 2019 15:27:19 +0200 [thread overview]
Message-ID: <20190713132719.sNRRfo1GKggQcb86_fyqeHd9vGKGI0d9XJ0ozjxhQ0A@z> (raw)
In-Reply-To: <gh-mailinglist-notifications-41a7ca26-5023-4802-975b-f1789d68868e-void-packages-13064@inbox.vuxu.org>
[-- Attachment #1: Type: text/plain, Size: 1638 bytes --]
New comment by q66 on void-packages repository
https://github.com/void-linux/void-packages/pull/13064#issuecomment-511122136
Comment:
Yeah, ELFv2 itself shouldn't make a massive difference, but some is better than none, especially if we can have it basically for free. Also, I wasn't expecting that to get merged right now, but whatever, I wasn't planning to do any more changes in it anyway, so might as well give it a try.
Btw, I'll also be switching the default page size from 64kB to 4kB. This should also make some difference on older hardware (G5 doesn't support 64k pages in hardware, so the kernel emulates them, first to support 64k is POWER8), I had some concerns about stuff that hardcodes 64k pages for ppc64 (like webengine, but turns out it just wastes a bit more memory without causing any harm) and also about running VM guests with 64k page size on 4k page hosts, and ext4 filesystems being incompatible, but I'm testing a 4k page kernel here right now and everything seems to be working.
Most distros take the choice of using 64kB pages on ppc64le nowadays, but there are few workloads that can benefit from it (and they're restricted exclusively to servers) and both page sizes are supported in hardware even on modern stuff, so I'll go with the more practical/compatible with the rest of the world option :) I never liked big default pages myself (here I agree with Linus Torvalds, who wrote a post on why default pages above 4kB are stupid), and if we can do away with them, that's for the best (makes guard pages practical again, besides other reasons...)
People who want 64k can compile their own kernel.
prev parent reply other threads:[~2019-07-13 13:27 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-12 17:48 [PR PATCH] " voidlinux-github
2019-07-13 3:01 ` voidlinux-github
2019-07-13 4:05 ` voidlinux-github
2019-07-13 4:29 ` voidlinux-github
2019-07-13 7:19 ` [PR PATCH] [Merged]: " voidlinux-github
2019-07-13 13:27 ` voidlinux-github [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190713132719.sNRRfo1GKggQcb86_fyqeHd9vGKGI0d9XJ0ozjxhQ0A@z \
--to=voidlinux-github@inbox.vuxu.org \
--cc=ml@inbox.vuxu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).