Changing the word-size was: Re: eat your own dog food?

[Arnaldo Carvalho de Melo <acme-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>]

Em Sat, Jan 12, 2008 at 01:21:09PM -0200, Arnaldo Carvalho de Melo escreveu:
> Em Thu, Jan 10, 2008 at 04:41:16PM -0500, jamal escreveu:
> > On Thu, 2008-10-01 at 19:39 -0200, Arnaldo Carvalho de Melo wrote:
> > 
> > 
> > > Working now on unions, etc, have you had the chance of testing this
> > > patch?
> > 
> > I should be able to test it in a couple of hours. If you have the unions
> > change before then, send me a unified patch - else an incremental
> > version.
> 
> Remove the non-commited patches and do a git-pull, basic work is done,
> reusing code I had in ctracer to do some simple alignment fixups.
> 
> Please let me know about any bugs you may find.

There are still some problems:

[acme@doppio pahole]$ build/pahole -C e1000_opt_list \
/usr/lib/debug/lib/modules/2.6.21-65.el5rt/kernel/drivers/net/e1000/e1000.ko.debug

struct e1000_opt_list {
	int                        i;                    /*     0     4 */

	/* XXX 4 bytes hole, try to pack */

	char *                     str;                  /*     8     8 */

	/* size: 16, cachelines: 1 */
	/* sum members: 12, holes: 1, sum holes: 4 */
	/* last cacheline: 16 bytes */
};

So on 64 bits we have a hole because pointers are aligned at word-size
boundaries, changing it to 4 bytes:

[acme@doppio pahole]$ build/pahole -w 4 -C e1000_opt_list \
/usr/lib/debug/lib/modules/2.6.21-65.el5rt/kernel/drivers/net/e1000/e1000.ko.debug
struct e1000_opt_list {
	int                        i;                    /*     0     4 */

	/* XXX 4 bytes hole, try to pack */

	char *                     str;                  /*     8     4 */

	/* size: 12, cachelines: 1 */
	/* sum members: 8, holes: 1, sum holes: 4 */
	/* last cacheline: 12 bytes */
};

The pointer size was correctly changed to 4 and the size reduced to 12,
but we should have subtracted 4 bytes from 'str' offset and the hole
would disappear and the size becomes 8.

Working on it.

This new feature should be more exploited on an upcoming cool feature,
one where we'll be able to ask pahole if a struct has optimal layout in
a range of architectures.

That should be a piece of cake to implement as we'll just clone each
struct, change the word size of it and check if with the new word-size
there are holes where previously there wasn't.

With full fledged alignment rules in description files for each
architecture we will be able to check on all arches if a struct is The
Holy Grail :-)

Ah, and if we find out that on one arch it is unholy, i.e. has
non-optimal layout, we can ask pahole to reorganize it and check again.

Humm, the reorganize (that jamal calls 'optimize') machinery will have
to take into account the rules for all the architectures... That should
be fun! :-P

- Arnaldo
-
To unsubscribe from this list: send the line "unsubscribe dwarves" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html