Messages in this thread |  | | | Date | Thu, 10 Nov 2005 15:38:18 +0000 (GMT) | | From | Hugh Dickins <> | | Subject | Re: [PATCH 01/15] mm: poison struct page for ptlock |
| |
On Thu, 10 Nov 2005, Ingo Molnar wrote: > * Hugh Dickins <hugh@veritas.com> 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |