linux-kernel - Re: [PATCH] Fix dirty page accounting in redirty_page_for

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 30 Apr 2009 09:13:44 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Ingo Molnar <mingo@...e.hu>
cc:	Christoph Lameter <cl@...ux.com>,
	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>,
	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, Tejun Heo <tj@...nel.org>
Subject: Re: [PATCH] Fix dirty page accounting in
 redirty_page_for_writepage()



On Thu, 30 Apr 2009, Ingo Molnar wrote:
> 
> nice. Do these all get called with irqs off, all the time?

There are lots of non-irq-off cases where non-atomic counters are safe. A 
couple of reasons:

 - counters that just don't care enough. Some statistics are very 
   important to always be exact, others are "helpful" but performance is 
   more important than being exactly right.

 - counters simply not accessed (or at least changed) from interrupts at 
   all. This is very common for some cases, notably "user event" stats. 
   They may need preemption support, but nothing fancier.

 - counters that are "idempotent" wrt interrupts. For example, anything 
   that will always count up and then down again in a paired fashion 
   (think kernel lock counter, preemption counter etc) is inherently safe 
   as a per-cpu counter without needing any protection at all, since any 
   interrupts may _change_ them, but will always change them back, so even 
   if a non-atomic sequence gets interrupted, it doesn't matter.

In fact, I'd argue that for a per-cpu counter, the whole _point_ of the 
exercise is almost always performance, so locked sequences would be bad to 
assume. The fact that x86 can do "atomic" per-cpu accesses with basically 
zero cost (by virtue of it's rmw memory ops) is unusual.

Most other architectures will have a very hard time making such counters 
cheap, since for them, there "irq atomicity" (expensive irq disable or 
store conditional) or "SMP atomicity" (the same fairly expensive 
store-conditional or something even worse).

				Linus
--
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/