On Thu, 10 Nov 2005, Ingo Molnar wrote:
> * Hugh Dickins <[email protected]> wrote:
> > Of course, someone may extend spinlock debugging info tomorrow; but
> > when they do, presumably they'll try it out, and hit the BUILD_BUG_ON.
> > They'll then probably want to extend the suppression in mm/Kconfig.
>
> why not do the union thing so that struct page grows automatically as
> new fields are added? It is quite bad design to introduce a hard limit
> like that. The only sizing concern is to make sure that the common
> .configs dont increase the size of struct page, but otherwise why not
> allow a larger struct page - it's for debugging only.
Yes, we wouldn't be worrying much about DEBUG_SPINLOCK enlarging struct
page (unnecessary as that currently is): it's the PREEMPT case adding
break_lock that's of concern (and only on 32-bit, I think: on all the
64-bits we'd have two unsigned ints in unsigned long private).
Going the union way doesn't give any more guarantee that another level
isn't using the fields, than the overlay way I did. Going the union
way, without enlarging the common struct page, seems to involve either
lots of abstraction edits all over the tree (break_lock coinciding with
with page->mapping on 32-bit), or ruling out gcc 2.95. Either seems to
me like a lose with no real win.
I'm certainly not arguing against break_lock itself: it's one of the
reasons why I went for a proper spinlock_t there; and agree with you
that trying to squeeze it in with the lock would likely go deep into
architectural complications.
Hugh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
