This is the mail archive of the
mailing list for the binutils project.
Re: [PATCH, PPC] Use 64k for COMMONPAGESIZE
- From: Sebastian Huber <sebastian dot huber at embedded-brains dot de>
- To: binutils at sourceware dot org
- Date: Thu, 18 Dec 2014 08:06:51 +0100
- 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 18/12/14 07:11, 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.
There are not only servers and desktops in the world. We have also
>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.
Since RTEMS uses its own linker command files, this change has no impact
on RTEMS. Otherwise it would be a problem since some chips have about
64KiB of RAM.
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : firstname.lastname@example.org
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.