linux-kernel - Re: [ltt-dev] [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 for Android: free password hash cracker in your pocket

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

Message-ID: <20090501202400.GA20280@Krystal>
Date:	Fri, 1 May 2009 16:24:00 -0400
From:	Mathieu Desnoyers <compudj@...stal.dyndns.org>
To:	Christoph Lameter <cl@...ux.com>
Cc:	Nick Piggin <nickpiggin@...oo.com.au>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Yuriy Lalym <ylalym@...il.com>, ltt-dev@...ts.casi.polymtl.ca,
	Tejun Heo <tj@...nel.org>, Ingo Molnar <mingo@...e.hu>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [ltt-dev] [PATCH] Fix dirty page accounting in
	redirty_page_for_writepage()

* Christoph Lameter (cl@...ux.com) wrote:
> On Fri, 1 May 2009, Mathieu Desnoyers wrote:
> 
> > What I do here is to let those u8 counters increment as free-running
> > counters. Yes, they will periodically overflow the 8 bits. But I don't
> > rely on this for counting the number of increments we need between
> > global counter updates : I use the bitmask taken from the threshold
> > value (which is now required to be a power of two) to detect 0, 1, 2, 3,
> > 4, 5, 6 or 7-bit counter overflow. Therefore we can still have the kind
> > of granularity currently provided. The only limitation is that we have
> > to use powers of two for the threshold, so we end up counting in power
> > of two modulo, which will be unaffected by the u8 overflow.
> 
> Ack. Got it. Looks good.
> 

Super ! :)

So, back to my original point : do you agree on the usefulness of
separating fallback irq-disabling from the per-cpu atomic construct ?

e.g. :

__inc_zone_state
  percpu_add_return_irq(var);

inc_zone_state
  percpu_irqsave(flags);
  __inc_zone_state()
  percpu_irqrestore(flags);

This would require that percpu_add_return_irq should always be called
either in :
  - irq disabled code paths
  - in code paths surrounded by percpu_irqsave/restore.

In this example :

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;

Mathieu

-- 
Mathieu Desnoyers
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
--
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/