[patch] CONFIG_ARCH_HAS_ATOMIC_UNSIGNED

[patch] CONFIG_ARCH_HAS_ATOMIC_UNSIGNED

[Dave Hansen]

This reduces another one of the dependencies that struct page's
definition has on any arch-specific header files.  Currently,
only x86_64 uses this, so it's the only architecture that needed
to be modified.

Signed-off-by: Dave Hansen <haveblue@us.ibm.com>
---

 apw2-dave/arch/x86_64/Kconfig         |    4 ++++
 apw2-dave/include/asm-x86_64/bitops.h |    2 --
 apw2-dave/include/linux/mm.h          |    2 +-
 apw2-dave/include/linux/mmzone.h      |    2 +-
 4 files changed, 6 insertions(+), 4 deletions(-)

diff -puN arch/x86_64/Kconfig~000-CONFIG_ARCH_HAS_ATOMIC_UNSIGNED arch/x86_64/Kconfig
--- apw2/arch/x86_64/Kconfig~000-CONFIG_ARCH_HAS_ATOMIC_UNSIGNED	2004-12-16 16:29:29.000000000 -0800
+++ apw2-dave/arch/x86_64/Kconfig	2004-12-16 16:30:48.000000000 -0800
@@ -193,6 +193,10 @@ config X86_LOCAL_APIC
 	bool
 	default y
 
+config ARCH_HAS_ATOMIC_UNSIGNED
+	bool
+	default y
+
 config MTRR
 	bool "MTRR (Memory Type Range Register) support"
 	---help---
diff -puN include/linux/mm.h~000-CONFIG_ARCH_HAS_ATOMIC_UNSIGNED include/linux/mm.h
--- apw2/include/linux/mm.h~000-CONFIG_ARCH_HAS_ATOMIC_UNSIGNED	2004-12-16 16:29:29.000000000 -0800
+++ apw2-dave/include/linux/mm.h	2004-12-16 16:30:57.000000000 -0800
@@ -216,7 +216,7 @@ struct vm_operations_struct {
 struct mmu_gather;
 struct inode;
 
-#ifdef ARCH_HAS_ATOMIC_UNSIGNED
+#ifdef CONFIG_ARCH_HAS_ATOMIC_UNSIGNED
 typedef unsigned page_flags_t;
 #else
 typedef unsigned long page_flags_t;
diff -puN include/linux/mmzone.h~000-CONFIG_ARCH_HAS_ATOMIC_UNSIGNED include/linux/mmzone.h
--- apw2/include/linux/mmzone.h~000-CONFIG_ARCH_HAS_ATOMIC_UNSIGNED	2004-12-16 16:29:29.000000000 -0800
+++ apw2-dave/include/linux/mmzone.h	2004-12-16 16:31:07.000000000 -0800
@@ -388,7 +388,7 @@ extern struct pglist_data contig_page_da
 
 #include <asm/mmzone.h>
 
-#if BITS_PER_LONG == 32 || defined(ARCH_HAS_ATOMIC_UNSIGNED)
+#if BITS_PER_LONG == 32 || defined(CONFIG_ARCH_HAS_ATOMIC_UNSIGNED)
 /*
  * with 32 bit page->flags field, we reserve 8 bits for node/zone info.
  * there are 3 zones (2 bits) and this leaves 8-2=6 bits for nodes.
diff -puN include/asm-x86_64/bitops.h~000-CONFIG_ARCH_HAS_ATOMIC_UNSIGNED include/asm-x86_64/bitops.h
--- apw2/include/asm-x86_64/bitops.h~000-CONFIG_ARCH_HAS_ATOMIC_UNSIGNED	2004-12-16 16:32:42.000000000 -0800
+++ apw2-dave/include/asm-x86_64/bitops.h	2004-12-16 16:32:48.000000000 -0800
@@ -411,8 +411,6 @@ static __inline__ int ffs(int x)
 /* find last set bit */
 #define fls(x) generic_fls(x)
 
-#define ARCH_HAS_ATOMIC_UNSIGNED 1
-
 #endif /* __KERNEL__ */
 
 #endif /* _X86_64_BITOPS_H */
_
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

Re: [patch] CONFIG_ARCH_HAS_ATOMIC_UNSIGNED

[Andi Kleen]

On Thu, Dec 16, 2004 at 04:44:20PM -0800, Dave Hansen wrote:
> 
> This reduces another one of the dependencies that struct page's
> definition has on any arch-specific header files.  Currently,
> only x86_64 uses this, so it's the only architecture that needed
> to be modified.

That's for page_flags_t, right?

I think it could be dropped right now and just use unsigned long for flags again. 

Since the objrmap work the saved 4 bytes in struct page are wasted in padding 
and I haven't found a way to use them for real space saving again
because all other members are 8 byte or paired 4 byte.

Of course if anybody could come up with a way to make struct page
smaller it would be very appreciated:

struct page {
        page_flags_t flags;             /* Atomic flags, some possibly
                                         * updated asynchronously */

			<------------ what to do with the 4 byte padding here?

        atomic_t _count;                /* Usage count, see below. */
        atomic_t _mapcount;             /* Count of ptes mapped in mms,
                                         * to show when page is mapped
                                         * & limit reverse map searches.
                                         */
        unsigned long private;          /* Mapping-private opaque data:
                                         * usually used for buffer_heads
                                         * if PagePrivate set; used for
                                         * swp_entry_t if PageSwapCache
                                         */
        struct address_space *mapping;  /* If low bit clear, points to
                                         * inode address_space, or NULL.
                                         * If page mapped as anonymous
                                         * memory, low bit is set, and
                                         * it points to anon_vma object:
                                         * see PAGE_MAPPING_ANON below.
                                         */
        pgoff_t index;                  /* Our offset within mapping. */
        struct list_head lru;           /* Pageout list, eg. active_list
                                         * protected by zone->lru_lock !
                                         */



-Andi
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

Re: [patch] CONFIG_ARCH_HAS_ATOMIC_UNSIGNED

[Dave Hansen]

On Thu, 2004-12-16 at 22:11, Andi Kleen wrote:
> On Thu, Dec 16, 2004 at 04:44:20PM -0800, Dave Hansen wrote:
> > This reduces another one of the dependencies that struct page's
> > definition has on any arch-specific header files.  Currently,
> > only x86_64 uses this, so it's the only architecture that needed
> > to be modified.
> 
> That's for page_flags_t, right?

Yep.

> I think it could be dropped right now and just use unsigned long for
> flags again. 

That's fine with me (and a much simpler patch).

> Since the objrmap work the saved 4 bytes in struct page are wasted in padding 
> and I haven't found a way to use them for real space saving again
> because all other members are 8 byte or paired 4 byte.

Well, since you asked... :)

In a newer revision of the nonlinear code, Andy Whitcroft has decided to
store part of the page_to_pfn() translation directly in page->flags,
right next to the zone information.  This is a bit of a squeeze on
32-bit arches, but on the 64-bit ones, there's plenty of room since
nobody is using the upper 32 bits at all.

I didn't realize that x86_64 had a 32-bit type there, so we probably
would have suggested turning it into a 64-bit one eventually.

-- Dave

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

Re: [patch] CONFIG_ARCH_HAS_ATOMIC_UNSIGNED

[Christoph Lameter]

On Fri, 17 Dec 2004, Andi Kleen wrote:

> struct page {
>         page_flags_t flags;             /* Atomic flags, some possibly
>                                          * updated asynchronously */
>
> 			<------------ what to do with the 4 byte padding here?
>

Put the order of the page there for compound pages instead of having that
in index?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

Re: [patch] CONFIG_ARCH_HAS_ATOMIC_UNSIGNED

[Andi Kleen]

On Fri, Dec 17, 2004 at 08:27:58AM -0800, Christoph Lameter wrote:
> 
> On Fri, 17 Dec 2004, Andi Kleen wrote:
> 
> > struct page {
> >         page_flags_t flags;             /* Atomic flags, some possibly
> >                                          * updated asynchronously */
> >
> > 			<------------ what to do with the 4 byte padding here?
> >
> 
> Put the order of the page there for compound pages instead of having that
> in index?

That would waste memory on the 64bit architectures that cannot tolerate
32bit atomic flags or on true 32bit architecture.

Also what's the problem of having it in index?

-Andi
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

Re: [patch] CONFIG_ARCH_HAS_ATOMIC_UNSIGNED

[Christoph Lameter]

On Fri, 17 Dec 2004, Andi Kleen wrote:

> > Put the order of the page there for compound pages instead of having that
> > in index?
>
> That would waste memory on the 64bit architectures that cannot tolerate
> 32bit atomic flags or on true 32bit architecture.

Would be great to have 64 bit atomic support to fill this hole then.

> Also what's the problem of having it in index?

It implies that huge pages cannot be handled in the same way as regular
pages. F.e. if huge pages should ever be able to map files then huge
pages will also need page->index. Maybe its best to encode the order in
a 64 bit page flags on 64 bit machines? It will be zero in most cases and
one could then simply check for having a hugepage and get to the first page
without a pointer if the huge pages are properly aligned in their address
space.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

Re: [patch] CONFIG_ARCH_HAS_ATOMIC_UNSIGNED

[Andi Kleen]

On Fri, Dec 17, 2004 at 11:26:49AM -0800, Christoph Lameter wrote:
> On Fri, 17 Dec 2004, Andi Kleen wrote:
> 
> > > Put the order of the page there for compound pages instead of having that
> > > in index?
> >
> > That would waste memory on the 64bit architectures that cannot tolerate
> > 32bit atomic flags or on true 32bit architecture.
> 
> Would be great to have 64 bit atomic support to fill this hole then.

I think you lost me.   How would that help?

To fill the hole you would need a 4 byte member with padding to move around,
but there isn't one. You cannot also just add one because it would waste 
memory on 32bit archs and other 64bit archs.

-Andi
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

Re: [patch] CONFIG_ARCH_HAS_ATOMIC_UNSIGNED

[Christoph Lameter]

On Fri, 17 Dec 2004, Andi Kleen wrote:

> On Fri, Dec 17, 2004 at 11:26:49AM -0800, Christoph Lameter wrote:
> > On Fri, 17 Dec 2004, Andi Kleen wrote:
> >
> > > > Put the order of the page there for compound pages instead of having that
> > > > in index?
> > >
> > > That would waste memory on the 64bit architectures that cannot tolerate
> > > 32bit atomic flags or on true 32bit architecture.
> >
> > Would be great to have 64 bit atomic support to fill this hole then.
>
> I think you lost me.   How would that help?

It would fill the hole on 64 bits if atomic_t would have the native word
size.

> To fill the hole you would need a 4 byte member with padding to move around,
> but there isn't one. You cannot also just add one because it would waste
> memory on 32bit archs and other 64bit archs.

There is no clean solution here but I just wanted to indicate what I would
like to see there if you want to use the space.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

Re: [patch] CONFIG_ARCH_HAS_ATOMIC_UNSIGNED

[Andi Kleen]

On Fri, Dec 17, 2004 at 02:11:59PM -0800, Christoph Lameter wrote:
> On Fri, 17 Dec 2004, Andi Kleen wrote:
> 
> > On Fri, Dec 17, 2004 at 11:26:49AM -0800, Christoph Lameter wrote:
> > > On Fri, 17 Dec 2004, Andi Kleen wrote:
> > >
> > > > > Put the order of the page there for compound pages instead of having that
> > > > > in index?
> > > >
> > > > That would waste memory on the 64bit architectures that cannot tolerate
> > > > 32bit atomic flags or on true 32bit architecture.
> > >
> > > Would be great to have 64 bit atomic support to fill this hole then.
> >
> > I think you lost me.   How would that help?
> 
> It would fill the hole on 64 bits if atomic_t would have the native word
> size.

The problem is that that 64bit atomic_t type would end up unaligned.
While that would work in theory on x86-64 I suspect it would be slow even
there. And it would probably not work anywhere else.

And as Dave said they plan to use the upper 32bit of flags for 
CONFIG_NONLINEAR anyways, so it's not even possible.

-Andi
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>