tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Improvements in amd64



On Fri, May 13, 2016 at 05:42:55PM +0200, Maxime Villard wrote:
> Le 13/05/2016 16:48, Martin Husemann a écrit :
> >On Fri, May 13, 2016 at 12:53:54PM +0200, Maxime Villard wrote:
> >>  - I took rodata out of the text+rodata chunk, and put it in the data+bss+
> >>    PRELOADED_MODULES+BOOTSTRAP_TABLES chunk [3].
> >
> >Why?
> >
> >You are probably assuming something obvious to you, but for folks
> >not too deep into x86 MMU handling (like me), this sounds like a very
> >strange thing to do.
> >
> >Martin
> >
> 
> What I wanted to achieve, from the beginning to the end, was mapping
> text with RX, rodata with R, and data+bss with RW, and optimize them
> with large pages.

That still doesn't make sense to me. I see no real advantage to waste
memory by forcefully splitting text and rodata. I still regulary deploy
virtual machines with 256MB or 512MB memory and wasting a decent chunk
of a large page just for the sake of purity doesn't help. What should be
used is:

- text is mapped with RX and a large pages
- rodata starts in the text segment and does not require flushing the
final large page of text
- any pages of rodata and other read-only content (like .eh_frame) after
the final large page of text are mapped read-only, using normal pages
necessary.

It might be useful to mark firmware images and the like to put them into
.rodata-late or something, to make it more likely that they go into the
less TLB friendly small page part, but that's a secondary optimisation.

I'm fine with having .data aligned to a 2MB boundary, but there should
be only one such alignment in the kernel. In short, I find mapping
read-only data as writeable to be much more harmful than mapping
read-only data as executable.

Joerg


Home | Main Index | Thread Index | Old Index