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 20:49 UTC|newest]
Thread overview: 22+ 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 ` [RFC 1/6] Framework Christoph Lameter
2005-12-10 3:32 ` Andi Kleen
2005-12-12 16:32 ` Christoph Lameter
2005-12-12 3:46 ` Nick Piggin
2005-12-12 3:56 ` Andi Kleen
2005-12-12 4:14 ` Nick Piggin
2005-12-12 4:21 ` Andi Kleen
2005-12-12 4:28 ` Nick Piggin
2005-12-12 4:51 ` Andi Kleen
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 ` [RFC 3/6] Make nr_pagecache " Christoph Lameter
2005-12-11 18:32 ` Marcelo Tosatti
2005-12-11 19:48 ` Andi Kleen
2005-12-11 20:49 ` Marcelo Tosatti [this message]
2005-12-12 3:51 ` Nick Piggin
2005-12-12 11:57 ` Marcelo Tosatti
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 ` [RFC 5/6] Make nr_slab a per zone counter Christoph Lameter
2005-12-10 0:55 ` [RFC 6/6] Make nr_pagecache " 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox