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
next prev parent 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