Re: + pg_uncached-is-ia64-only.patch added to -mm tree

[Andy Whitcroft <apw@shadowen.org>]

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/