/me finds it rather amusing, in a sad way, that desktop developers again have to discuss such things. Welcome to the club :-/
On Wednesday 26 April 2006 07:07, Behdad Esfahbod wrote: > On Tue, 25 Apr 2006, Federico Mena Quintero wrote: > > But yeah, even if we get down to 4 KB per library, it still becomes a > > big number when you consider 4 KB * num_libraries * num_processes. > > AFAIU, other than prelinking, there's no reason that the GOT > tables have to be page-aligned and per library. Or is it? The GOT is not page-aligned. It's simply just that as soon as you write once to it, one page gets dirty. And given that .got, .data and other writable sections are together, and you're 99.999999% (maybe even 100%, I don't know) guaranteed to have at least one write somewhere, you're bound to have at least one dirty page per library per process. GOT (and other writable sections) have to be per library because a) they may contain data (i.e. already in the binary), e.g. .data may contain variables with initial values, in .got some relocations contain initial offset and are just adjusted - this could be solved by copying such sections to a contiguous block of memory though b) data in them are referred to using an offset, so the data have to be at a certain offset from the code (the PIC base register). If these data were moved to another place, I don't see how the code would be able to easily find the moved base address. Given that the layout of libraries varies per various processes, the moved address would vary as well[*]. I would have to check the ELF spec to be 100% sure about this though. [*] Hmm, thinking of that, mapping all .data etc. at a certain absolute address with some mapping table at the beginning could do, at least in theory. -- Lubos Lunak KDE developer --------------------------------------------------------------------- SuSE CR, s.r.o. e-mail: [EMAIL PROTECTED] , [EMAIL PROTECTED] Drahobejlova 27 tel: +420 2 9654 2373 190 00 Praha 9 fax: +420 2 9654 2374 Czech Republic http://www.suse.cz/ _______________________________________________ Performance-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/performance-list
