linux-kernel - Re: [patch 0/7] cpuset writeback throttling

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, 31 Oct 2008 08:47:19 -0500 (CDT)
From:	Christoph Lameter <cl@...ux-foundation.org>
To:	Dave Chinner <david@...morbit.com>
cc:	David Rientjes <rientjes@...gle.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Nick Piggin <npiggin@...e.de>,
	Peter Zijlstra <peterz@...radead.org>,
	Paul Menage <menage@...gle.com>, Derek Fults <dfults@....com>,
	linux-kernel@...r.kernel.org
Subject: Re: [patch 0/7] cpuset writeback throttling

On Fri, 31 Oct 2008, Dave Chinner wrote:

> Yes, I know about those tests at SGI - they were to demonstrate the
> feature worked (i.e. proof-of-concept demonstration), not regression
> test the change.

I did some regression tests at that time before publishing the initial 
patchsets. That was mainly using standard tests (AIM7). There have been 
some changes since then though.

> This is a fairly major change in behaviour to the writeback path on
> NUMA systems and so has the potential to introduce subtle new
> issues. Hence I'm asking about the level of testing and exposure
> it has had. It doesn't really sound like it has had much coverage
> to me....

Sure we need more testing. Solomita did some testing as evident from his 
messages. See f.e. 
http://linux.derkeiler.com/Mailing-Lists/Kernel/2007-09/msg02939.html

> I'm concerned right now because Nick and others (including myself)
> have recently found lots of nasty data integrity problems in the
> writeback path that we are currently trying to test fixes for.
> It's not a good time to introduce new behaviours as that will
> definitely perturb any regression testing we are running....

The writeback throttling that is addressed in the patchset mainly changes 
the calculation of the limits that determine when writeback is started and 
select inodes based on their page allocation on certain nodes. That is 
relatively independent of the locking scheme for writeback.
--
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/