Andrew Morton wrote:
> KAMEZAWA Hiroyuki <[email protected]> wrote:
>
>>Hi, Andrew
>>
>>On Thu, 06 Apr 2006 21:20:26 -0700
>>[email protected] 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 [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]
