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


* Mathieu Desnoyers <compudj@krystal.dyndns.org> wrote:

> * Ingo Molnar (mingo@elte.hu) wrote:
> > 
> > * Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> wrote:
> > 
> > > And thanks for the review! This excercise only convinced me that 
> > > the kernel memory accounting works as expected. All this gave me 
> > > the chance to have a good look at the memory accounting code. We 
> > > could probably benefit of Christoph Lameter's cpu ops (using 
> > > segment registers to address per-cpu variables with atomic 
> > > inc/dec) in there. Or at least removing interrupt disabling by 
> > > using preempt disable and local_t variables for the per-cpu 
> > > counters could bring some benefit.
> > 
> > Note, optimized per cpu ops are already implemented upstream, by 
> > Tejun Heo's percpu patches in .30:
> > 
> >  #define percpu_read(var)	percpu_from_op("mov", per_cpu__##var)
> >  #define percpu_write(var, val)	percpu_to_op("mov", per_cpu__##var, val)
> >  #define percpu_add(var, val)	percpu_to_op("add", per_cpu__##var, val)
> >  #define percpu_sub(var, val)	percpu_to_op("sub", per_cpu__##var, val)
> >  #define percpu_and(var, val)	percpu_to_op("and", per_cpu__##var, val)
> >  #define percpu_or(var, val)	percpu_to_op("or", per_cpu__##var, val)
> >  #define percpu_xor(var, val)	percpu_to_op("xor", per_cpu__##var, val)
> > 
> > See:
> > 
> >   6dbde35: percpu: add optimized generic percpu accessors
> > 
> > From the changelog:
> > 
> >     [...]
> >     The advantage is that for example to read a local percpu variable,
> >     instead of this sequence:
> >     
> >      return __get_cpu_var(var);
> >     
> >      ffffffff8102ca2b:  48 8b 14 fd 80 09 74    mov    -0x7e8bf680(,%rdi,8),%rdx
> >      ffffffff8102ca32:  81
> >      ffffffff8102ca33:  48 c7 c0 d8 59 00 00    mov    $0x59d8,%rax
> >      ffffffff8102ca3a:  48 8b 04 10             mov    (%rax,%rdx,1),%rax
> >     
> >     We can get a single instruction by using the optimized variants:
> >     
> >      return percpu_read(var);
> >     
> >      ffffffff8102ca3f:  65 48 8b 05 91 8f fd    mov    %gs:0x7efd8f91(%rip),%rax
> >     [...]
> > 
> > So if you want to make use of it, percpu_add()/percpu_sub() would be 
> > the place to start.
> > 
> 
> Great !
> 
> I see however that it's only guaranteed to be atomic wrt preemption.

That's really only true for the non-x86 fallback defines. If we so 
decide, we could make the fallbacks in asm-generic/percpu.h irq-safe 
...

> What would be even better would be to have the atomic ops wrt local irqs
> (as local.h does) available in this percpu flavor. By doing this, we
> could have interrupt and nmi-safe per-cpu counters, without even the
> need to disable preemption.

nmi-safe isnt a big issue (we have no NMI code that interacts with 
MM counters) - and we could make them irq-safe by fixing the 
wrapper. (and on x86 they are NMI-safe too.)

	Ingo

  reply	other threads:[~2009-04-30  6:52 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 [this message]
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
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=20090430065055.GA16277@elte.hu \
    --to=mingo@elte.hu \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=cl@linux.com \
    --cc=compudj@krystal.dyndns.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ltt-dev@lists.casi.polymtl.ca \
    --cc=nickpiggin@yahoo.com.au \
    --cc=thomas.pi@arcor.dea \
    --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