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:	Fri, 1 May 2009 23:06:28 -0400 (EDT)
From:	Christoph Lameter <cl@...ux.com>
To:	Ingo Molnar <mingo@...e.hu>
cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	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 Fri, 1 May 2009, Ingo Molnar wrote:

> > I see but it may take some time for me to get that finished
> > (probably 2 weeks or so). Dont feel that you have to merge my old
> > patches or a variant thereof.
>
> it's your baby really and i dont want to interfere in any negative
> way. The patches look fairly complete and you did all the hard work
> with them already.

Ah I remember, you drowned that baby when you asked me to do lowercase
macros. That plus the job change made me to lose most of my drive for the
patchset. No employer anymore that wants the stuff... Then there is the
scheduler regression and the network latency issues that prevent my new
project from running kernels after 2.6.22. Time that I have will be mostly
spend on that in the coming weeks. Cannot really push much into newer
kernels until we are able to run upstream kernels without significant loss
in performance.

We just tried 2.6.9. And hey performance is better. Looks like going back
in kernel versions is a way to improve performance. Simpler kernel,
lower cache footprint and it becomes faster. And the app is simply
doing network I/O and some number crunching. Sigh.

> Can help out with review and testing (as always) but i suspect it's
> more appropriate for -mm to carry them in the end, because of the MM
> and tree-wide impact, and because the fine differences between those
> APIs will only be truly visible on non-x86.

I'd be glad to review. But this is not far up in the priority list given
the unresolved regressions.

> ( There's also Tejun's latest improvements of the dynamic allocator
>   that he made based on your feedback - are those in any tree yet? )

No idea. Do not see them upstream.
--
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/