Re: [PATCH] only irq-safe atomic ops

Andrew Morton (akpm@zip.com.au)
Fri, 22 Feb 2002 22:51:46 -0800


Robert Love wrote:
>
> The following patch implements i386 versions of atomic_inc and
> atomic_dec that are LOCK-less but provide IRQ-atomicity and act as a
> memory-barrier.
>
> An applicable use would be data that needs to be IRQ-safe but not
> SMP-safe (or, more likely, is already SMP-safe for some other reason).
>
> Additionally, these variants could prevent having to use
> preempt_disable/enable or "full" atomic ops around per-CPU data with a
> preemptible kernel.
>

Thanks, Robert.

Some background here - for the delayed allocation code which I'm
cooking up I need to globally count the number of dirty pages in the
machine. Currently that's done with atomic_inc(&nr_dirty_pages)
in SetPageDirty().

But this counter (which is used for when-to-start-writeback decisions)
is unavoidably approximate. It would be nice to make it a per-CPU
array. So on the rare occasions when the dirty-page count is needed,
I can just whizz across the per-cpu counters adding them all up.

But how to increment or decrement a per-cpu counter? The options
are:

- per_cpu_integer++;

This is *probably* OK on all architectures. But there are no
guarantees that the compiler won't play games, and that this
operation is preempt-safe.

- preempt_disable(); per_cpu_counter++; preempt_enable();

A bit heavyweight for add-one-to-i.

- atomic_inc

A buslocked operation where it is not needed - we only need
a preempt-locked operation here. But it's per-cpu data, and
the buslocked rmw won't be too costly.

I can't believe how piddling this issue is :)

But if there's a general need for such a micro-optimisation
then we need to:

1: Create <linux/atomic.h> (for heavens sake!)

2: In <linux/atomic.h>,

#ifndef ARCH_HAS_ATOMIC_INQ_THINGIES
#define atomic_inc_irq atomic_inc
...
#endif

But for now, I suggest we not bother. I'll just use atomic_inc().

-
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/