On Fri, 2010-04-23 at 13:17 -0700, Greg Thelen wrote: > > This is an interesting idea. If this applies to memcg dirty accounting, > then would it also apply to system-wide dirty accounting? I don't think > so, but I wanted to float the idea. It looks like this proportions.c > code is good is at comparing the rates of events (for example: per-task > dirty page events). However, in the case of system-wide dirty > accounting we also want to consider the amount of dirty memory, not just > the rate at which it is being dirtied. Correct, the whole proportion thing is purely about comparing rates of events. > The performance of simple irqsave locking or more advanced RCU locking > is similar to current locking (non-irqsave/non-rcu) for several > workloads (kernel build, dd). Using a micro-benchmark some differences > are seen: > * irqsave is 1% slower than mmotm non-irqsave/non-rcu locking. > * RCU locking is 4% faster than mmotm non-irqsave/non-rcu locking. > * RCU locking is 5% faster than irqsave locking. Depending on what architecture you care about local_t might also be an option, it uses per-cpu irq/nmi safe instructions (and falls back to local_irq_save/restore for architectures lacking this support). -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>