All of lore.kernel.org
 help / color / mirror / Atom feed
From: Adrian Bunk <bunk@stusta.de>
To: Christoph Lameter <clameter@engr.sgi.com>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linux-ia64@ver.kernel.org, ak@suse.de
Subject: Re: [RFC] Introduce atomic_long_t
Date: Fri, 9 Dec 2005 21:11:28 +0100	[thread overview]
Message-ID: <20051209201127.GE23349@stusta.de> (raw)
In-Reply-To: <Pine.LNX.4.62.0512091053260.2656@schroedinger.engr.sgi.com>

On Fri, Dec 09, 2005 at 10:58:40AM -0800, Christoph Lameter wrote:

> Several counters already have the need to use 64 atomic variables on 64
> bit platforms (see mm_counter_t in sched.h). We have to do ugly ifdefs to
> fall back to 32 bit atomic on 32 bit platforms.
> 
> The VM statistics patch that I am working on will also need to make more 
> extensive use of 64 bit counters when available.
> 
> This patch introduces a new type atomic_long_t that works similar to the c
> "long" type. Its 32 bits on 32 bit platforms and 64 bits on 64 bit platforms.
> 
> The patch uses atomic_long_t to clean up the mess in include/linux/sched.h.
> Implementations for all arches provided but only tested on ia64.
>...

The idea looks good, but the amount of code duplication is ugly.

What about creating an include/linux/atomic.h [1] that contains both 
this new code and other common code like the atomic_t typedef (unless 
there's a good reason why counter isn't volatile on h8300 and v850...).

cu
Adrian

[1] include/asm-generic/atomic.h would be another solution, but for
    an API that should be available on all architectures, include/linux/
    seems to be the more logical place

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed


WARNING: multiple messages have this Message-ID (diff)
From: Adrian Bunk <bunk@stusta.de>
To: Christoph Lameter <clameter@engr.sgi.com>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linux-ia64@ver.kernel.org, ak@suse.de
Subject: Re: [RFC] Introduce atomic_long_t
Date: Fri, 9 Dec 2005 21:11:28 +0100	[thread overview]
Message-ID: <20051209201127.GE23349@stusta.de> (raw)
In-Reply-To: <Pine.LNX.4.62.0512091053260.2656@schroedinger.engr.sgi.com>

On Fri, Dec 09, 2005 at 10:58:40AM -0800, Christoph Lameter wrote:

> Several counters already have the need to use 64 atomic variables on 64
> bit platforms (see mm_counter_t in sched.h). We have to do ugly ifdefs to
> fall back to 32 bit atomic on 32 bit platforms.
> 
> The VM statistics patch that I am working on will also need to make more 
> extensive use of 64 bit counters when available.
> 
> This patch introduces a new type atomic_long_t that works similar to the c
> "long" type. Its 32 bits on 32 bit platforms and 64 bits on 64 bit platforms.
> 
> The patch uses atomic_long_t to clean up the mess in include/linux/sched.h.
> Implementations for all arches provided but only tested on ia64.
>...

The idea looks good, but the amount of code duplication is ugly.

What about creating an include/linux/atomic.h [1] that contains both 
this new code and other common code like the atomic_t typedef (unless 
there's a good reason why counter isn't volatile on h8300 and v850...).

cu
Adrian

[1] include/asm-generic/atomic.h would be another solution, but for
    an API that should be available on all architectures, include/linux/
    seems to be the more logical place

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

--
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:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2005-12-09 20:11 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-09 18:58 [RFC] Introduce atomic_long_t Christoph Lameter
2005-12-09 18:58 ` Christoph Lameter
2005-12-09 20:11 ` Adrian Bunk [this message]
2005-12-09 20:11   ` Adrian Bunk
2005-12-09 21:57   ` Christoph Lameter
2005-12-09 21:57     ` Christoph Lameter
2005-12-09 22:02     ` Adrian Bunk
2005-12-09 22:02       ` Adrian Bunk
2005-12-09 22:20       ` Andi Kleen
2005-12-09 22:20         ` Andi Kleen
2005-12-09 22:33         ` Adrian Bunk
2005-12-09 22:33           ` Adrian Bunk
2005-12-09 22:50           ` Andi Kleen
2005-12-09 22:50             ` Andi Kleen
2005-12-09 22:58             ` Adrian Bunk
2005-12-09 22:58               ` Adrian Bunk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20051209201127.GE23349@stusta.de \
    --to=bunk@stusta.de \
    --cc=ak@suse.de \
    --cc=clameter@engr.sgi.com \
    --cc=linux-ia64@ver.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.