So maybe what is needed is really a separate mapfile directive, like "text = S0x400000" meaning Fill the segment up to the spec'd boundary. Like the .skip pseudo op in assembly. Or something like that.
> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Wednesday, March 01, 2006 1:44 PM > To: David McDaniel (damcdani) > Cc: perf-discuss@opensolaris.org > Subject: Re: [perf-discuss] Arificial enlargement of binaries > to enable VMPSS aks auto mpss > > Functionality wise, rounding in mapfile is not supposed to > increase the size of the segment. It introduces an address > space hole from the end of the segment to the roundup > address. That is the reason why the text segment is still > being mapped with 8K pages (with the mapfile trick), and > there is no change in ITLB misses. > > I just filed the bug number 6392464. Due to the bug, the > binary sees an extra 4M size in this particular case, and > also, a separate non-required 4M page is being created (which > was not supposed to be created - .interp section offset is 4M). > > Dev > > > David McDaniel wrote: > > A binary is less 4M and demonstrates high ITLB miss rates. > I decide to experiment with making it larger to address the issue. > > The first approach was to assemble the following .s file > and link it into the target binaries: > > .section ".text" > > .align 4096*1024 > > .skip 8 > > > > This resulted in an enlarged binary which does get mapped > on 4M boundary and which results in ~50% reduction in > ITLB_miss rates as reported by cputrack. > > > > Thinking this business of linking in bogus .o files to be > pretty ugly, I tried to use a mapfile as follows to perhaps > more effectively and simply achieve the same result: > > > > text = A0x400000; > > text = R0x400000; > > > > This also results in an enlarged binary but does *not* > result in a reduction in ITLB_miss rates. Upon further > investigation, it appears that the mapfile option does not > behave as expected: > > > > # dump -h a.out > > > > a.out: > > > > **** SECTION HEADER TABLE **** > > [No] Type Flags Addr Offset Size Name > > Link Info Adralgn Entsize > > > > [1] 1 2 0x800000 0x400000 0x11 > .interp > > 0 0 0x400000 0 > > > > [2] 5 2 0x800014 0x400014 0x42ec > .hash > > 3 0 0x4 0x4 > > > > [3] 11 2 0x804300 0x404300 0x85c0 > .dynsym > > 4 1 0x4 0x10 > > > > [4] 3 34 0x80c8c0 0x40c8c0 0x14ec0 > .dynstr > > 0 0 0x1 0 > > > > [5] 1879048190 2 0x821780 0x421780 > 0x50 .SUNW_version > > 4 2 0x4 0 > > > > [6] 4 66 0x8217d0 0x4217d0 0xc > .rela.data > > 3 17 0x4 0xc > > > > [7] 4 66 0x8217dc 0x4217dc 0x1e0 > .rela.bss > > 3 19 0x4 0xc > > > > [8] 4 66 0x8219bc 0x4219bc 0xed0 > .rela.plt > > 3 15 0x4 0xc > > > > [9] 1 6 0x822890 0x422890 0x313488 > .text > > 0 0 0x8 0 > > > > [10] 1 6 0xb35d18 0x735d18 0x10 > .init > > 0 0 0x4 0 > > > > [11] 1 6 0xb35d28 0x735d28 0xc > .fini > > 0 0 0x4 0 > > > > ... and so forth. > > > > Despite the mapfile directive, the text section is not > aligned and not rounded up. The .interp section however > *does* appear to have been rounded up. I'm inclined to think > the problem is simply that I dont know what the heck I'm > doing. Any ideas? > > This message posted from opensolaris.org > > _______________________________________________ > > perf-discuss mailing list > > perf-discuss@opensolaris.org > _______________________________________________ perf-discuss mailing list perf-discuss@opensolaris.org
