Re: [PATCH 2/2] x86, boot: Optimize the elf header handling.
From: Eric W. Biederman
Date: Sun Jul 01 2012 - 16:40:40 EST
"H. Peter Anvin" <hpa@xxxxxxxxx> writes:
> On 07/01/2012 12:20 PM, Eric W. Biederman wrote:
>> Grumble Grumble.
>> If I force a 2M alignment, poffsets and paddrs align and my previous
>> patches work. Although I don't expect that to be more than a testing
>> Meanwhile if I force a 4K max page size for most purposes things look
>> better from a file offset perspective. But the data segment is now less
>> aligned in the file than it is in memory and my patches don't work.
>> I feel like I have stumbled into pandoras box.
> Last I looked at this we didn't actually have a general PHDR parser...
> are you running into its limitations?
Sort of. It was my premise that we should not need a general PHDR
parser, or even a parser at all , especially since a general PHDR parser
is hard to fit into the existing bzImage protocol. So far emperically
except when dealing with the weird percpu section we don't need a
general PHDR parser.
There is just enough weirdness that it makes sense to have a
phdr parser that just verifies it doesn't need to do anything.
So I have tracked down part of the crazyness.
CONFIG_RODATA actually uses 2MB alignment, making
-z max_page_size=4096 a bit questionable.
In practice I'm not concerned with a few extra zero's in the file
because giant runs of zeros compress very well.
I am going to play with the percpu section a bit more and see if
I can remove the need for magic to get it's p_offset and p_paddr
to be aligned in the file, as that comes for free with everything
Hmm. I think I see why the percpu section is problematic. We have to
specify AT on all of our sections and the usual formula is
".section : AT(.section - LOAD_OFFSET)". Unfortunately that doesn't
work when we we set the virtual address to zero.
I will play with it a little more and see if I can come up with
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/