Messages in this thread | | | Date | Thu, 20 Dec 2007 14:08:22 -0800 | From | Jeremy Fitzhardinge <> | Subject | Re: [PATCH 0/5] x86: another attempt at x86 pagetable unification |
| |
Ingo Molnar wrote: > * Jeremy Fitzhardinge <jeremy@goop.org> wrote: > > >>> found a couple of bugs. >>> >>> firstly, 64-bit wasnt so lucky, you broke >>> iounmap()/change_page_attr() >>> :-) >>> >> Crap. Worked for me. I'll look into it. >> > > well, there's an easy solution for unification patches: the resulting > object files must have _exactly the same_ content as without the > unification patches. (Modulo strings as WARN_ON()s referring to > include-file names.) > > If they differ then the unification did something wrong. With your > patchset and the config i sent, the difference is visible in the image > size already: > > text data bss dec hex filename > 7763766 967330 5812328 14543424 ddea40 vmlinux.after > 7763811 967330 5812328 14543469 ddea6d vmlinux.before > > also, reducing the size and scope of changes helps as well - because > that way it can be bisected down to specific changes. Mistakes > inevitably happen, especially if you do not enforce a rigid > byte-for-byte correctness along the way. You did 5 rather large patches, > and it's not testable because your unification steps were too coarse. >
But byte-for-byte identity isn't (necessarily) possible when actually unifying. If the same function exists in different forms on 32- and 64-bit, then unifying requires I pick one of them (or perhaps a new superset) to use in the unified form. That function may generate different code compared to the one that it replaced...
But you're right, I can do the patches in a more piecemeal form. I'll see if I can rework them.
J
| |