Subject: Re: `__attribute__ ((__aligned__))' has gotta go
To: None <firstname.lastname@example.org, email@example.com>
From: Ross Harvey <firstname.lastname@example.org>
Date: 10/23/1999 15:56:28
> From: email@example.com (Christos Zoulas)
> In article <199910231944.TAA18725@orchard.arlington.ma.us>,
> Bill Sommerfeld <firstname.lastname@example.org> wrote:
> >The presence of __attribute__((__aligned__)) is probably partly my
> >fault (lockwords on PA-RISC have to be 16-byte aligned; Jason seemed
> >to think that this would be the Way To Go to make this happen).
> >Deleting it for now is probably the best bet; we can probably find a
> >less painful alternative should we ever port to an SMP HP7xx/8xx
> I'll take partial blame for that too, because I suggested to use the
> __aligned__. OTOH, it is really stupid of gcc to use aligned for a
> data type, to mean the maximum page alignment of the machine. Anyway
> the solution is what eeh suggested, move it to md code and use=
> __attribute__((__aligned__(<n>))) as necessary.
On top of all those reasons, it is somewhat likely that a different mechanism
would be used on the hypothetical HP port anyway.
Dynamically allocated kernel structures can explode by many megabytes when
you make the locks bigger, because there are so many locks. Adding more
swap space or memory adds lots more locks, too. (I think this is because
vm_anon's are allocated one per page plus one per swap space page, and they
each have a lock.) An HP port might motivate us to make an indirect lock
or some other sort of trick.
So, I just went in and axed the __attribute__() making no other changes.
It's unused even in SMP kernels and isn't necessarily what would be used
even on HPPA.
Plus, it would be nice from my point of view not to churn the lock code
yet again while I have > 4,000 lines of SMP diffs uncommitted. :-) :-)