From: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
To: Andi Kleen <ak@suse.de>
Cc: Christoph Lameter <clameter@sgi.com>,
linux-kernel@vger.kernel.org, Hugh Dickins <hugh@veritas.com>,
Nick Piggin <nickpiggin@yahoo.com.au>,
linux-mm@kvack.org
Subject: Re: [RFC 3/6] Make nr_pagecache a per zone counter
Date: Sun, 11 Dec 2005 18:49:43 -0200 [thread overview]
Message-ID: <20051211204943.GA4375@dmt.cnet> (raw)
In-Reply-To: <20051211194840.GU11190@wotan.suse.de>
On Sun, Dec 11, 2005 at 08:48:40PM +0100, Andi Kleen wrote:
> > By the way, why does nr_pagecache needs to be an atomic variable on UP systems?
>
> At least on X86 UP atomic doesn't use the LOCK prefix and is thus quite
> cheap. I would expect other architectures who care about UP performance
> (= not IA64) to be similar.
But in practice the variable does not need to be an atomic type for UP, but
simply a word, since stores are atomic on UP systems, no?
Several arches seem to use additional atomicity instructions on
atomic functions:
PPC:
static __inline__ void atomic_add(int a, atomic_t *v)
{
int t;
__asm__ __volatile__(
"1: lwarx %0,0,%3 # atomic_add\n\
add %0,%2,%0\n"
PPC405_ERR77(0,%3)
" stwcx. %0,0,%3 \n\
bne- 1b"
: "=&r" (t), "=m" (v->counter)
: "r" (a), "r" (&v->counter), "m" (v->counter)
: "cc");
}
"lwarx" and "stwcx." wouldnt be necessary for updating nr_pagecache
on UP.
SPARC:
int __atomic_add_return(int i, atomic_t *v)
{
int ret;
unsigned long flags;
spin_lock_irqsave(ATOMIC_HASH(v), flags);
ret = (v->counter += i);
spin_unlock_irqrestore(ATOMIC_HASH(v), flags);
return ret;
}
WARNING: multiple messages have this Message-ID (diff)
From: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
To: Andi Kleen <ak@suse.de>
Cc: Christoph Lameter <clameter@sgi.com>,
linux-kernel@vger.kernel.org, Hugh Dickins <hugh@veritas.com>,
Nick Piggin <nickpiggin@yahoo.com.au>,
linux-mm@kvack.org
Subject: Re: [RFC 3/6] Make nr_pagecache a per zone counter
Date: Sun, 11 Dec 2005 18:49:43 -0200 [thread overview]
Message-ID: <20051211204943.GA4375@dmt.cnet> (raw)
In-Reply-To: <20051211194840.GU11190@wotan.suse.de>
On Sun, Dec 11, 2005 at 08:48:40PM +0100, Andi Kleen wrote:
> > By the way, why does nr_pagecache needs to be an atomic variable on UP systems?
>
> At least on X86 UP atomic doesn't use the LOCK prefix and is thus quite
> cheap. I would expect other architectures who care about UP performance
> (= not IA64) to be similar.
But in practice the variable does not need to be an atomic type for UP, but
simply a word, since stores are atomic on UP systems, no?
Several arches seem to use additional atomicity instructions on
atomic functions:
PPC:
static __inline__ void atomic_add(int a, atomic_t *v)
{
int t;
__asm__ __volatile__(
"1: lwarx %0,0,%3 # atomic_add\n\
add %0,%2,%0\n"
PPC405_ERR77(0,%3)
" stwcx. %0,0,%3 \n\
bne- 1b"
: "=&r" (t), "=m" (v->counter)
: "r" (a), "r" (&v->counter), "m" (v->counter)
: "cc");
}
"lwarx" and "stwcx." wouldnt be necessary for updating nr_pagecache
on UP.
SPARC:
int __atomic_add_return(int i, atomic_t *v)
{
int ret;
unsigned long flags;
spin_lock_irqsave(ATOMIC_HASH(v), flags);
ret = (v->counter += i);
spin_unlock_irqrestore(ATOMIC_HASH(v), flags);
return ret;
}
--
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>
next prev parent reply other threads:[~2005-12-11 21:53 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-10 0:54 [RFC 0/6] Zoned VM stats Christoph Lameter
2005-12-10 0:54 ` Christoph Lameter
2005-12-10 0:54 ` [RFC 1/6] Framework Christoph Lameter
2005-12-10 0:54 ` Christoph Lameter
2005-12-10 3:32 ` Andi Kleen
2005-12-10 3:32 ` Andi Kleen
2005-12-12 16:32 ` Christoph Lameter
2005-12-12 16:32 ` Christoph Lameter
2005-12-12 3:46 ` Nick Piggin
2005-12-12 3:46 ` Nick Piggin
2005-12-12 3:56 ` Andi Kleen
2005-12-12 3:56 ` Andi Kleen
2005-12-12 4:14 ` Nick Piggin
2005-12-12 4:14 ` Nick Piggin
2005-12-12 4:21 ` Andi Kleen
2005-12-12 4:21 ` Andi Kleen
2005-12-12 4:28 ` Nick Piggin
2005-12-12 4:28 ` Nick Piggin
2005-12-12 4:51 ` Andi Kleen
2005-12-12 4:51 ` Andi Kleen
2005-12-12 7:05 ` Nick Piggin
2005-12-12 7:05 ` Nick Piggin
2005-12-10 0:54 ` [RFC 2/6] Make nr_mapped a per zone counter Christoph Lameter
2005-12-10 0:54 ` Christoph Lameter
2005-12-10 0:54 ` [RFC 3/6] Make nr_pagecache " Christoph Lameter
2005-12-10 0:54 ` Christoph Lameter
2005-12-11 18:32 ` Marcelo Tosatti
2005-12-11 18:32 ` Marcelo Tosatti
2005-12-11 19:48 ` Andi Kleen
2005-12-11 19:48 ` Andi Kleen
2005-12-11 20:49 ` Marcelo Tosatti [this message]
2005-12-11 20:49 ` Marcelo Tosatti
2005-12-12 3:51 ` Nick Piggin
2005-12-12 3:51 ` Nick Piggin
2005-12-12 11:57 ` Marcelo Tosatti
2005-12-12 11:57 ` Marcelo Tosatti
2005-12-12 16:34 ` Christoph Lameter
2005-12-12 16:34 ` Christoph Lameter
2005-12-10 0:55 ` [RFC 4/6] Expanded node and zone statistics Christoph Lameter
2005-12-10 0:55 ` Christoph Lameter
2005-12-10 0:55 ` [RFC 5/6] Make nr_slab a per zone counter Christoph Lameter
2005-12-10 0:55 ` Christoph Lameter
2005-12-10 0:55 ` [RFC 6/6] Make nr_pagecache " Christoph Lameter
2005-12-10 0:55 ` Christoph Lameter
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=20051211204943.GA4375@dmt.cnet \
--to=marcelo.tosatti@cyclades.com \
--cc=ak@suse.de \
--cc=clameter@sgi.com \
--cc=hugh@veritas.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=nickpiggin@yahoo.com.au \
/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.