Messages in this thread | | | Date | Sat, 08 Apr 2006 16:41:47 +0100 | From | Andy Whitcroft <> | Subject | Re: + pg_uncached-is-ia64-only.patch added to -mm tree |
| |
Andrew Morton wrote: > KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote: > >>Hi, Andrew >> >>On Thu, 06 Apr 2006 21:20:26 -0700 >>akpm@osdl.org wrote: >> >> >>>The patch titled >>> >>> PG_uncached is ia64 only >>> >>>has been added to the -mm tree. Its filename is >>> >>> pg_uncached-is-ia64-only.patch >>> >>>See http://www.zip.com.au/~akpm/linux/patches/stuff/added-to-mm.txt to find >>>out what to do about this >>> >> >>in include/linux/mmzone.h >>== >>#elif BITS_PER_LONG == 64 >>/* >> * with 64 bit flags field, there's plenty of room. >> */ >>#define FLAGS_RESERVED 32 >> >>#else > > > OK. > > >>it looks this is used here. >> >>#if SECTIONS_WIDTH+NODES_WIDTH+ZONES_WIDTH > FLAGS_RESERVED >>#error SECTIONS_WIDTH+NODES_WIDTH+ZONES_WIDTH > FLAGS_RESERVED >>#endif >> >>I'm not sure but please compile check FLAGS_RESRVED with SPARSEMEM or >> > > > Yes, that test won't trigger. > > >>#if (BITS_PER_LONG > 32) /* 64-bit only flags. we can use full >> low 32bits */ >>#define PG_uncached 31 >>#endif >> >>Hm..Is this ugly ? :( > > > It's easier to change FLAGS_RESERVED ;) > > diff -puN include/linux/page-flags.h~pg_uncached-is-ia64-only include/linux/page-flags.h > --- devel/include/linux/page-flags.h~pg_uncached-is-ia64-only 2006-04-06 21:50:51.000000000 -0700 > +++ devel-akpm/include/linux/page-flags.h 2006-04-06 21:50:51.000000000 -0700 > @@ -7,6 +7,8 @@ > > #include <linux/percpu.h> > #include <linux/cache.h> > +#include <linux/types.h> > + > #include <asm/pgtable.h> > > /* > @@ -86,7 +88,10 @@ > #define PG_mappedtodisk 16 /* Has blocks allocated on-disk */ > #define PG_reclaim 17 /* To be reclaimed asap */ > #define PG_nosave_free 18 /* Free, should not be written */ > -#define PG_uncached 19 /* Page has been mapped as uncached */ > + > +#if (BITS_PER_LONG > 32) > +#define PG_uncached 32 /* Page has been mapped as uncached */ > +#endif
As Hiroyuki-san points out we can need up to 30 bits to encode large 64 bit machines right now. Reducing the space available for FIELDS but reducing FLAGS_RESERVED for 64 bit machines will negativly impact them when SPARSEMEM is enabled. I think it makes much more sense here to use the bits which have been released by the movement of the FIELDS upwards in the 64 bit case.
32 bit -------------------------------| FIELDS | FLAGS | 64 bit | FIELDS | ?????? FLAGS | 63 32 0
Logically we should in the general case have FLAGS_RESERVED in 64 bit be the value for 32 bit + 32; currently 9 + 32. If we desire to have 64 bit only flags then it seems keeping FLAGS_RESERVED at 32 for 64 bit would leave '32 bit FIELDS' segment free for those flags.
In short with the current values of FLAGS_RESERVED I would think starting at 31 working downwards towards the 'common'/32 bit flags would be the most logical.
Cheers.
-apw - 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/
| |