From: Mathieu Desnoyers <compudj@krystal.dyndns.org>
To: Christoph Lameter <cl@linux.com>
Cc: 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>,
ltt-dev@lists.casi.polymtl.ca, Tejun Heo <tj@kernel.org>,
Ingo Molnar <mingo@elte.hu>,
Linus Torvalds <torvalds@linux-foundation.org>,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [ltt-dev] [PATCH] Fix dirty page accounting in redirty_page_for_writepage()
Date: Fri, 1 May 2009 16:43:55 -0400 [thread overview]
Message-ID: <20090501204355.GB20280@Krystal> (raw)
In-Reply-To: <alpine.DEB.1.10.0905011623450.16255@qirst.com>
* Christoph Lameter (cl@linux.com) wrote:
> On Fri, 1 May 2009, Mathieu Desnoyers wrote:
>
> > So, back to my original point : do you agree on the usefulness of
> > separating fallback irq-disabling from the per-cpu atomic construct ?
>
> No. Percpu operations are used for statistics and are like atomic
> operations. Aggregation of these leads to a can of worms that we better
> leave unopened.
>
> > x86 would map :
> >
> > percpu_irqsave/restore to "nothing".
> > percpu_add_return_irq to xadd instruction. It is irq-safe by design.
> >
> > Other architectures (fallback) would map
> >
> > percpu_irqsave/restore to local_irq_save/restore.
> > percpu_add_return_irq to var += value; return var;
>
> Shudder.... We have explored those types of macros before (while doing
> fastpath optimization for SLUB) and it significant increases the
> complexity. People may add additional instructions in between and now
> interrupts off could be on or off depending on the architecture. Sometimes
> percpu_irqsave does nothing. Very difficult to ensure that the usage is
> correct.
>
> And we have barely any usage case for such macros.
>
Then do you have a better idea on how to deal with
__inc_zone_state/inc_zone_state without duplicating the code and without
adding useless local_irq_save/restore on x86 ?
Mathieu
--
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
next prev parent reply other threads:[~2009-05-01 20:44 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
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 [this message]
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=20090501204355.GB20280@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