This is the mail archive of the
mailing list for the binutils project.
Re: [PATCH, PPC] Use 64k for COMMONPAGESIZE
- From: Alan Modra <amodra at gmail dot com>
- To: Chris Johns <chrisj at rtems dot org>, Richard Henderson <rth at redhat dot com>, Binutils <binutils at sourceware dot org>, Adhemerval Zanella <azanella at linux dot vnet dot ibm dot com>
- Date: Fri, 19 Dec 2014 18:46:33 +1030
- Subject: Re: [PATCH, PPC] Use 64k for COMMONPAGESIZE
- Authentication-results: sourceware.org; auth=none
- References: <5490DDB2 dot 9020706 at redhat dot com> <5492110B dot 1060405 at rtems dot org> <20141218061119 dot GB23483 at bubble dot grove dot modra dot org>
On Thu, Dec 18, 2014 at 04:41:19PM +1030, Alan Modra wrote:
> On Thu, Dec 18, 2014 at 10:26:03AM +1100, Chris Johns wrote:
> > On 17/12/2014 12:34 pm, Richard Henderson wrote:
> > >It seems to me that most powerpc hardware these days is server based, and very
> > >little remains at the desktop class.
> > What about embedded devices with as Freescale's QorIQ T2080 and T4240 ?
> > >And in the server environment, IBM has
> > >been recommending a 64k page size.
> > Would this change effect RTEMS and it devices ?
> Yes, it would. However, the effect isn't huge one way or another.
> Richard quoting IBM's recommendation of a 64k page size really hasn't
> anything to do with COMMONPAGESIZE, or at least not as much as you
> might think.. You can quite happily run a binary linked with
> COMMONPAGESIZE set to 4k on a system using 64k pages. COMMONPAGESIZE
> or -z common-page-size is really about where the linker starts the
> data segment, following on from the text segment. It boils down to
> a trade-off between memory pages and disk pages, and the net result of
> increasing COMMONPAGESIZE to 64k for a system running with 4k pages
> is that you'll tend to have bigger on-disk binaries but won't use any
> more memory than with the "proper" 4k COMMONPAGESIZE. On the other
> hand if you really are running with 64k pages, there will be binaries
> where you could save a 64k page of memory if you'd specified the
> proper COMMONPAGESIZE at link time.
> Overall, I think the increased COMMONPAGESIZE is beneficial, so I'm
> happy with the patch.
One other thing I'd forgotten about is that COMMONPAGESIZE is used to
decide where the relro segment ends (which after reading some bug
reports, I guess is the driving force behind this patch). This
particular usage *can* increase memory footprint so my "won't use more
memory" remark above is incorrect.
You could argue that using COMMONPAGESIZE for this purpose is a bug,
and that MAXPAGESIZE should determine the relro segment end instead..
Australia Development Lab, IBM