Re: [PATCH] Fix dirty page accounting inredirty_page_for_writepage()

[Ingo Molnar]

* Christoph Lameter <cl@xxxxxxxxx> wrote:

> http://article.gmane.org/gmane.linux.kernel.cross-arch/1128
> http://article.gmane.org/gmane.linux.kernel.cross-arch/1132
> http://article.gmane.org/gmane.linux.kernel.cross-arch/1134
> http://article.gmane.org/gmane.linux.kernel.cross-arch/1138
> http://article.gmane.org/gmane.linux.kernel.cross-arch/1139
> http://article.gmane.org/gmane.linux.kernel.cross-arch/1145 VM stats
> http://article.gmane.org/gmane.linux.kernel.cross-arch/1160 NFS stats
> http://article.gmane.org/gmane.linux.kernel.cross-arch/1161 Genhd stats
> http://article.gmane.org/gmane.linux.kernel.cross-arch/1164 SRCU

The new percpu APIs could be used in most of these places already, 
straight away. This is a really good TODO list for places to 
enhance.

Then a second set of patches could convert percpu_add() / etc. uses 
to __percpu_add() ... but that should be done by those architectures 
that need it (and to the extent they need it), because it's not 
really testable on x86.

I dont really like the PER_CPU / CPU_INC etc. type of all-capitals 
APIs you introduced in the patches above:


+		__CPU_INC(bt->sequence);
+	CPU_FREE(bt->sequence);

was there any strong reason to go outside the well-established 
percpu_* name space and call these primitives as if they were 
macros?

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/