public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Mathieu Desnoyers <compudj@krystal.dyndns.org>
To: Christoph Lameter <cl@linux.com>
Cc: Ingo Molnar <mingo@elte.hu>,
	Nick Piggin <nickpiggin@yahoo.com.au>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Yuriy Lalym <ylalym@gmail.com>, Tejun Heo <tj@kernel.org>,
	ltt-dev@lists.casi.polymtl.ca,
	Andrew Morton <akpm@linux-foundation.org>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [ltt-dev] [PATCH] Fix dirty page accounting in redirty_page_for_writepage()
Date: Thu, 30 Apr 2009 15:41:58 -0400	[thread overview]
Message-ID: <20090430194158.GB12926@Krystal> (raw)
In-Reply-To: <alpine.DEB.1.10.0904301009530.14178@qirst.com>

* Christoph Lameter (cl@linux.com) wrote:
> On Thu, 30 Apr 2009, Mathieu Desnoyers wrote:
> 
> > > The 3 variants on x86 generate the same instructions. On other platforms
> > > they would need to be able to fallback in various way depending on the
> > > availability of instructions that are atomic vs. preempt or irqs.
> > >
> >
> > The problem here, as we did figure out a while ago with the atomic
> > slub we worked on a while ago, is that if we have the following code :
> >
> > local_irq_save
> > var++
> > var++
> > local_irq_restore
> >
> > that we would like to turn into irq-safe percpu variant with this
> > semantic :
> >
> > percpu_add_irqsafe(var)
> > percpu_add_irqsafe(var)
> >
> > We are generating two irq save/restore in the fallback, which will be
> > slow.
> >
> > However, we could do the following trick :
> >
> > percpu_irqsave(flags);
> > percpu_add_irq(var);
> > percpu_add_irq(var);
> > percpu_irqrestore(flags);
> 
> Hmmm.I do not remember any of those double ops in the patches that I did a
> while back for this. It does not make sense either because atomic per cpu
> ops are only atomic for a single instruction. You are trying to extend
> that so that multiple "atomic" instructions are now atomic.
> 

Hrm, not exactly. So I probably chose the naming of the primitives
poorly here if my idea seems unclear. Here is what I am trying to do :

On architectures with irq-safe percpu_add :
- No need to disable interrupts at all

On archs lacking such irq-safe percpu_add :
- disabling interrupts only once for a sequence of percpu counter operations.

I tried to come up with an example in vmstat where multiple percpu ops
would be required, but I figured out that the code needs to be changed
to support percpu ops correctly. However separating
percpu_irqsave/restore from percpu_add_return_irq lets us express
__inc_zone_state and inc_zone_state cleanly, which would be difficult
otherwise.

Let's assume we change the stat_threshold values in mm/vmstat.c so they
become power of 2 (so we don't care when the u8 overflow occurs so it
becomes a free running counter). This model does not support
"overstep" (yet).

Then assume :

        u8 stat_threshold_mask = pcp->stat_threshold - 1;

mm/vmstat.c :

void __inc_zone_state(struct zone *zone, enum zone_stat_item item)
{
        ... assuming p references percpu "u8" counters ...
        u8 p_new;

        p_new = percpu_add_return_irq(p, 1);

        if (unlikely(!(p_new & pcp->stat_threshold_mask)))
                zone_page_state_add(pcp->stat_threshold, zone, item);
}


void inc_zone_state(struct zone *zone, enum zone_stat_item item)
{
        unsigned long flags;

        /*
         * Disabling interrupts _only_ on architectures lacking atomic
         * percpu_*_irq ops.
         */
        percpu_irqsave(flags);
        __inc_zone_state(zone, item);
        percpu_irqrestore(flags);
}

void __dec_zone_state(struct zone *zone, enum zone_stat_item item)
{
        ... assuming p references percpu "u8" counters ...
        u8 p_new;

        p_new = percpu_sub_return_irq(p, 1);

        if (unlikely(!(p_new & pcp->stat_threshold_mask)))
                zone_page_state_add(-(pcp->stat_threshold), zone, item);
}

void dec_zone_state(struct zone *zone, enum zone_stat_item item)
{
        unsigned long flags;

        /*
         * Disabling interrupts _only_ on architectures lacking atomic
         * percpu_*_irq ops.
         */
        percpu_irqsave(flags);
        __dec_zone_state(zone, item);
        percpu_irqrestore(flags);
}

void __mod_zone_state(struct zone *zone, enum zone_stat_item item, long delta)
{
        ... assuming p references percpu "u8" counters ...

        u8 p_new;
        long overflow_delta;

        p_new = percpu_add_return_irq(p, delta);

        /*
         * We must count the number of threshold overflow generated by
         * "delta". I know, this looks rather odd.
         */
        overflow_delta = ((long)p_new & ~(long)pcp->stat_threshold_mask)
                         - (((long)p_new - delta)
                           & ~(long)pcp->stat_threshold_mask);

        if (unlikely(abs(overflow_delta) > pcp->stat_threshold_mask))
                zone_page_state_add(glob_delta, zone, item);
}

void mod_zone_state(struct zone *zone, enum zone_stat_item item, long delta)
{
        unsigned long flags;

        /*
         * Disabling interrupts _only_ on architectures lacking atomic
         * percpu_*_irq ops.
         */
        percpu_irqsave(flags);
        __mod_zone_state(zone, item, detlta);
        percpu_irqrestore(flags);
}

Note that all the fast-path would execute with preemption enabled if the
architecture supports irqsave percpu atomic ops.

So as we can see, if cpu ops are used on _different_ atomic counters,
then it may require multiple percpu ops in sequence. However, in the
vmstat case, given the version currently in mainline uses a sequence of
operations on the same variable, this requires re-engineering the
structure, because otherwise races with preemption would occur.

disclaimer : the code above has been written in a email client and may
not compile/work/etc etc.

Mathieu

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

  reply	other threads:[~2009-04-30 19:42 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-29 23:25 [PATCH] Fix dirty page accounting in redirty_page_for_writepage() Mathieu Desnoyers
2009-04-29 23:56 ` Mathieu Desnoyers
2009-04-29 23:59 ` Andrew Morton
2009-04-30  2:34   ` Mathieu Desnoyers
2009-04-30  0:06 ` Linus Torvalds
2009-04-30  2:43   ` Mathieu Desnoyers
2009-04-30  6:21     ` Ingo Molnar
2009-04-30  6:33       ` [ltt-dev] " Mathieu Desnoyers
2009-04-30  6:50         ` Ingo Molnar
2009-04-30 13:38           ` Christoph Lameter
2009-04-30 14:10             ` Ingo Molnar
2009-04-30 14:12             ` Mathieu Desnoyers
2009-04-30 14:12               ` Christoph Lameter
2009-04-30 19:41                 ` Mathieu Desnoyers [this message]
2009-04-30 20:17                   ` Christoph Lameter
2009-04-30 21:17                     ` Mathieu Desnoyers
2009-05-01 13:44                       ` Christoph Lameter
2009-05-01 19:21                         ` Mathieu Desnoyers
2009-05-01 19:31                           ` Christoph Lameter
2009-05-01 20:24                             ` Mathieu Desnoyers
2009-05-01 20:28                               ` Christoph Lameter
2009-05-01 20:43                                 ` Mathieu Desnoyers
2009-05-01 20:42                                   ` Christoph Lameter
2009-05-01 21:19                                     ` Mathieu Desnoyers
2009-05-02  3:00                                       ` Christoph Lameter
2009-05-02  7:01                                         ` Mathieu Desnoyers
2009-05-02 21:01                             ` Mathieu Desnoyers
2009-05-04 14:08                               ` Christoph Lameter
2009-05-03  2:40       ` Tejun Heo
2009-05-04 14:10         ` Christoph Lameter
2009-04-30 13:22     ` Christoph Lameter
2009-04-30 13:38       ` Ingo Molnar
2009-04-30 13:40         ` Christoph Lameter
2009-04-30 14:14           ` Ingo Molnar
2009-04-30 14:15             ` Christoph Lameter
2009-04-30 14:38               ` Ingo Molnar
2009-04-30 14:45                 ` Christoph Lameter
2009-04-30 15:01                   ` Ingo Molnar
2009-04-30 15:25                     ` Christoph Lameter
2009-04-30 15:42                       ` Ingo Molnar
2009-04-30 15:44                         ` Christoph Lameter
2009-04-30 16:06                           ` Ingo Molnar
2009-04-30 16:11                             ` Christoph Lameter
2009-04-30 16:16                             ` Linus Torvalds
2009-04-30 17:23                               ` Ingo Molnar
2009-04-30 18:07                                 ` Christoph Lameter
2009-05-01 19:59                                   ` Ingo Molnar
2009-05-01 20:35                                     ` Christoph Lameter
2009-05-01 21:07                                       ` Ingo Molnar
2009-05-02  3:06                                         ` Christoph Lameter
2009-05-02  9:03                                           ` Ingo Molnar
2009-05-04 14:48                                             ` Christoph Lameter
2009-04-30 16:13                         ` Linus Torvalds
2009-04-30 15:54                       ` Ingo Molnar
2009-04-30 16:00                       ` Ingo Molnar
2009-04-30 16:08                         ` Christoph Lameter
2009-04-30 13:50         ` Mathieu Desnoyers
2009-04-30 13:55           ` Christoph Lameter
2009-04-30 14:32           ` Ingo Molnar
2009-04-30 14:42             ` Christoph Lameter
2009-04-30 14:59               ` Ingo Molnar
2009-04-30 16:03             ` [ltt-dev] " Mathieu Desnoyers

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=20090430194158.GB12926@Krystal \
    --to=compudj@krystal.dyndns.org \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=cl@linux.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ltt-dev@lists.casi.polymtl.ca \
    --cc=mingo@elte.hu \
    --cc=nickpiggin@yahoo.com.au \
    --cc=tj@kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=ylalym@gmail.com \
    /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