From: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: Andi Kleen <ak@suse.de>, Christoph Lameter <clameter@sgi.com>,
linux-kernel@vger.kernel.org, Hugh Dickins <hugh@veritas.com>,
linux-mm@kvack.org
Subject: Re: [RFC 3/6] Make nr_pagecache a per zone counter
Date: Mon, 12 Dec 2005 09:57:31 -0200 [thread overview]
Message-ID: <20051212115731.GA3599@dmt.cnet> (raw)
In-Reply-To: <439CF3B1.4050803@yahoo.com.au>
On Mon, Dec 12, 2005 at 02:51:13PM +1100, Nick Piggin wrote:
> Marcelo Tosatti wrote:
> >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:
> >
>
> Yeah, this is to protect from interrupts and is common to most
> load store architectures. It is possible we could have
> atomic_xxx_irq / atomic_xxx_irqsave functions for these, however
> I think nobody has yet demostrated the improvements outweigh the
> complexity that would be added.
Hi Nick,
But nr_pagecache is not accessed at interrupt code, is it? It does
not need to be an atomic type.
WARNING: multiple messages have this Message-ID (diff)
From: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: Andi Kleen <ak@suse.de>, Christoph Lameter <clameter@sgi.com>,
linux-kernel@vger.kernel.org, Hugh Dickins <hugh@veritas.com>,
linux-mm@kvack.org
Subject: Re: [RFC 3/6] Make nr_pagecache a per zone counter
Date: Mon, 12 Dec 2005 09:57:31 -0200 [thread overview]
Message-ID: <20051212115731.GA3599@dmt.cnet> (raw)
In-Reply-To: <439CF3B1.4050803@yahoo.com.au>
On Mon, Dec 12, 2005 at 02:51:13PM +1100, Nick Piggin wrote:
> Marcelo Tosatti wrote:
> >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:
> >
>
> Yeah, this is to protect from interrupts and is common to most
> load store architectures. It is possible we could have
> atomic_xxx_irq / atomic_xxx_irqsave functions for these, however
> I think nobody has yet demostrated the improvements outweigh the
> complexity that would be added.
Hi Nick,
But nr_pagecache is not accessed at interrupt code, is it? It does
not need to be an atomic type.
--
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-12 12:51 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
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 [this message]
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=20051212115731.GA3599@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.