lkml.org 
[lkml]   [2005]   [Nov]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 01/15] mm: poison struct page for ptlock
Andrew Morton <akpm@osdl.org> wrote:
>
> Hugh Dickins <hugh@veritas.com> wrote:
> >
> > The split ptlock patch enlarged the default SMP PREEMPT struct page from
> > 32 to 36 bytes on most 32-bit platforms, from 32 to 44 bytes on PA-RISC
> > 7xxx (without PREEMPT). That was not my intention, and I don't believe
> > that split ptlock deserves any such slice of the user's memory.
> >
> > Could we please try this patch, or something like it? Again to overlay
> > the spinlock_t from &page->private onwards, with corrected BUILD_BUG_ON
> > that we don't go too far; with poisoning of the fields overlaid, and
> > unsplit SMP config verifying that the split config is safe to use them.
> >
> > The previous attempt at this patch broke ppc64, which uses slab for its
> > page tables - and slab saves vital info in page->lru: but no config of
> > spinlock_t needs to overwrite lru on 64-bit anyway; and the only 32-bit
> > user of slab for page tables is arm26, which is never SMP i.e. all the
> > problems came from the "safety" checks, not from what's actually needed.
> > So previous checks refined with #ifdefs, and a BUG_ON(PageSlab) added.
> >
> > This overlaying is unlikely to be portable forever: but the added checks
> > should warn developers when it's going to break, long before any users.
>
> argh.
>
> Really, I'd prefer to abandon gcc-2.95.x rather than this. Look:
>
> struct a
> {
> union {
> struct {
> int b;
> int c;
> };
> int d;
> };
> } z;
>
> main()
> {
> z.b = 1;
> z.d = 1;
> }
>
> It does everything we want.

It occurs to me that we can do the above if (__GNUC__ > 2), or whatever.

That way, the only people who have a 4-byte-larger pageframe are those who
use CONFIG_PREEMPT, NR_CPUS>=4 and gcc-2.x.y. An acceptably small
community, I suspect.


-
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/

\
 
 \ /
  Last update: 2005-11-15 19:52    [W:0.102 / U:0.268 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site