[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <49FD040B.4040705@gmail.com>
Date: Sun, 03 May 2009 11:40:11 +0900
From: Tejun Heo <htejun@...il.com>
To: Ingo Molnar <mingo@...e.hu>
CC: Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Nick Piggin <nickpiggin@...oo.com.au>,
KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>, thomas.pi@...or.dea,
Yuriy Lalym <ylalym@...il.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
ltt-dev@...ts.casi.polymtl.ca, Christoph Lameter <cl@...ux.com>
Subject: Re: [PATCH] Fix dirty page accounting in redirty_page_for_writepage()
Hello, Ingo.
Ingo Molnar wrote:
> * Mathieu Desnoyers <mathieu.desnoyers@...ymtl.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
One problem I have with the above api is that those take the variable
symbol not pointer to it, so they can't be used with dynamic
variables. The api needs major revisions anyway regarding atomicity
and I was planning on getting back to it once the all archs have been
converted and hoping that it wouldn't be used widely before that,
but then again it's not like changing percpu api and its users is
difficult thing to do and there are a lot of benefits in testing how
things work as soon as possible.
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists