From: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
To: Christoph Lameter <clameter@sgi.com>
Cc: linux-kernel@vger.kernel.org, akpm@osdl.org,
Hugh Dickins <hugh@veritas.com>,
Nick Piggin <nickpiggin@yahoo.com.au>,
linux-mm@kvack.org, Andi Kleen <ak@suse.de>
Subject: Re: [RFC3 02/14] Basic counter functionality
Date: Sat, 17 Dec 2005 02:19:50 -0200 [thread overview]
Message-ID: <20051217041950.GA7710@dmt.cnet> (raw)
In-Reply-To: <20051217040115.GA6975@dmt.cnet>
> There is no need to disable interrupts AFAICS, but only preemption
> (which could cause problems as your comment above describes). I suppose
> that these counters are not accessed at interrupt time and are not meant
> to be, right?
>
> Which means that if an interrupt happens at any point in the code,
> the state will be consistent after the IRQ(s) handler(s) finish and
> execution restarts where it had been interrupted.
>
> Why not use preempt_disable/preempt_enable? Those would disappear
> if !CONFIG_PREEMPT, and could be faster than the interrupt
> disabling/enabling (no need to save "flags" on stack, but increment
> preempt count, which has a chance to be on cache, I guess).
Which is what local_t does for BITS_PER_LONG==32 arches:
#define LOCAL_INIT(i) { ATOMIC_INIT(i) }
#define local_read(l) ((unsigned long)atomic_read(&(l)->a))
#define local_set(l,i) atomic_set((&(l)->a),(i))
#define local_inc(l) atomic_inc(&(l)->a)
#define local_dec(l) atomic_dec(&(l)->a)
#define local_add(i,l) atomic_add((i),(&(l)->a))
#define local_sub(i,l) atomic_sub((i),(&(l)->a))
/* Non-atomic variants, ie. preemption disabled and won't be touched
* in interrupt, etc. Some archs can optimize this case well. */
#define __local_inc(l) local_set((l), local_read(l) + 1)
#define __local_dec(l) local_set((l), local_read(l) - 1)
#define __local_add(i,l) local_set((l), local_read(l) + (i))
#define __local_sub(i,l) local_set((l), local_read(l) - (i))
> It would also be nice to have all code related to debugging only
> counters selectable at compile time, since it might not be interesting
> data for some scenarios (but unnecessary bloat) - seems that was the
> original intent by Andrew as you noted.
WARNING: multiple messages have this Message-ID (diff)
From: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
To: Christoph Lameter <clameter@sgi.com>
Cc: linux-kernel@vger.kernel.org, akpm@osdl.org,
Hugh Dickins <hugh@veritas.com>,
Nick Piggin <nickpiggin@yahoo.com.au>,
linux-mm@kvack.org, Andi Kleen <ak@suse.de>
Subject: Re: [RFC3 02/14] Basic counter functionality
Date: Sat, 17 Dec 2005 02:19:50 -0200 [thread overview]
Message-ID: <20051217041950.GA7710@dmt.cnet> (raw)
In-Reply-To: <20051217040115.GA6975@dmt.cnet>
> There is no need to disable interrupts AFAICS, but only preemption
> (which could cause problems as your comment above describes). I suppose
> that these counters are not accessed at interrupt time and are not meant
> to be, right?
>
> Which means that if an interrupt happens at any point in the code,
> the state will be consistent after the IRQ(s) handler(s) finish and
> execution restarts where it had been interrupted.
>
> Why not use preempt_disable/preempt_enable? Those would disappear
> if !CONFIG_PREEMPT, and could be faster than the interrupt
> disabling/enabling (no need to save "flags" on stack, but increment
> preempt count, which has a chance to be on cache, I guess).
Which is what local_t does for BITS_PER_LONG==32 arches:
#define LOCAL_INIT(i) { ATOMIC_INIT(i) }
#define local_read(l) ((unsigned long)atomic_read(&(l)->a))
#define local_set(l,i) atomic_set((&(l)->a),(i))
#define local_inc(l) atomic_inc(&(l)->a)
#define local_dec(l) atomic_dec(&(l)->a)
#define local_add(i,l) atomic_add((i),(&(l)->a))
#define local_sub(i,l) atomic_sub((i),(&(l)->a))
/* Non-atomic variants, ie. preemption disabled and won't be touched
* in interrupt, etc. Some archs can optimize this case well. */
#define __local_inc(l) local_set((l), local_read(l) + 1)
#define __local_dec(l) local_set((l), local_read(l) - 1)
#define __local_add(i,l) local_set((l), local_read(l) + (i))
#define __local_sub(i,l) local_set((l), local_read(l) - (i))
> It would also be nice to have all code related to debugging only
> counters selectable at compile time, since it might not be interesting
> data for some scenarios (but unnecessary bloat) - seems that was the
> original intent by Andrew as you noted.
--
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-17 4:20 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-15 0:14 [RFC3 00/14] Zoned VM stats Christoph Lameter
2005-12-15 0:14 ` Christoph Lameter
2005-12-15 0:14 ` [RFC3 01/14] Add some consts for inlines in mm.h Christoph Lameter
2005-12-15 0:14 ` Christoph Lameter
2005-12-15 1:01 ` J.A. Magallon
2005-12-15 1:01 ` J.A. Magallon
2005-12-15 0:14 ` [RFC3 02/14] Basic counter functionality Christoph Lameter
2005-12-15 0:14 ` Christoph Lameter
2005-12-17 4:01 ` Marcelo Tosatti
2005-12-17 4:01 ` Marcelo Tosatti
2005-12-17 4:19 ` Marcelo Tosatti [this message]
2005-12-17 4:19 ` Marcelo Tosatti
2005-12-19 17:58 ` Christoph Lameter
2005-12-19 17:58 ` Christoph Lameter
2005-12-15 0:14 ` [RFC3 03/14] Convert nr_mapped Christoph Lameter
2005-12-15 0:14 ` Christoph Lameter
2005-12-15 0:14 ` [RFC3 04/14] Convert nr_pagecache Christoph Lameter
2005-12-15 0:14 ` Christoph Lameter
2005-12-15 0:14 ` [RFC3 05/14] Resurrect scan_control.may_swap Christoph Lameter
2005-12-15 0:14 ` Christoph Lameter
2005-12-15 0:14 ` [RFC3 06/14] Zone Reclaim Christoph Lameter
2005-12-15 0:14 ` Christoph Lameter
2005-12-15 0:14 ` [RFC3 07/14] Expanded node and zone statistics Christoph Lameter
2005-12-15 0:14 ` Christoph Lameter
2005-12-15 0:14 ` [RFC3 08/14] Convert nr_slab Christoph Lameter
2005-12-15 0:14 ` Christoph Lameter
2005-12-15 0:15 ` [RFC3 09/14] Convert nr_page_table Christoph Lameter
2005-12-15 0:15 ` Christoph Lameter
2005-12-15 0:15 ` [RFC3 10/14] Convert nr_dirty Christoph Lameter
2005-12-15 0:15 ` Christoph Lameter
2005-12-15 0:15 ` [RFC3 11/14] Convert nr_writeback Christoph Lameter
2005-12-15 0:15 ` Christoph Lameter
2005-12-15 0:15 ` [RFC3 12/14] Convert nr_unstable Christoph Lameter
2005-12-15 0:15 ` Christoph Lameter
2005-12-15 0:15 ` [RFC3 13/14] Remove get_page_state functions Christoph Lameter
2005-12-15 0:15 ` Christoph Lameter
2005-12-15 0:15 ` [RFC3 14/14] Remove wbs Christoph Lameter
2005-12-15 0:15 ` Christoph Lameter
-- strict thread matches above, loose matches on Subject: below --
2005-12-15 0:31 [RFC3 00/14] Zoned VM stats Christoph Lameter
2005-12-15 0:32 ` [RFC3 02/14] Basic counter functionality 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=20051217041950.GA7710@dmt.cnet \
--to=marcelo.tosatti@cyclades.com \
--cc=ak@suse.de \
--cc=akpm@osdl.org \
--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.