[Top] [All Lists]

Re: [PATCH 2/4] XFS: Use the inode tree for finding dirty inodes

To: Eric Sandeen <sandeen@xxxxxxxxxxx>
Subject: Re: [PATCH 2/4] XFS: Use the inode tree for finding dirty inodes
From: Mark Goodwin <markgw@xxxxxxx>
Date: Wed, 23 Jul 2008 14:04:06 +1000
Cc: Christoph Hellwig <hch@xxxxxxxxxxxxx>, xfs@xxxxxxxxxxx
In-reply-to: <4886A9A3.8090805@xxxxxxxxxxx>
Organization: SGI Engineering
References: <1216556394-17529-1-git-send-email-david@xxxxxxxxxxxxx> <1216556394-17529-3-git-send-email-david@xxxxxxxxxxxxx> <20080722042829.GB27123@xxxxxxxxxxxxx> <20080722053019.GI6761@disturbed> <20080722072733.GA15376@xxxxxxxxxxxxx> <20080723000548.GG5947@disturbed> <488692FB.1010101@xxxxxxx> <4886A9A3.8090805@xxxxxxxxxxx>
Reply-to: markgw@xxxxxxx
Sender: xfs-bounce@xxxxxxxxxxx
User-agent: Thunderbird (Windows/20080421)

Eric Sandeen wrote:
Mark Goodwin wrote:
Dave Chinner wrote:
On Tue, Jul 22, 2008 at 03:27:33AM -0400, Christoph Hellwig wrote:
I only fear
we'll never get it in with the current review and commit latencies
for XFS :(
I can see this being a big issue in the not-too-distant future.....
[getting off-topic for this thread, but anyway ..]
This is already a big issue, obviously, and has been for some time.

Internally, we're attempting to refine our patch acceptance processes,
(e.g. gitify our internal dev tree and mirror it on oss so it's much
easier to push back out to oss). But the QA overhead remains a stubborn
problem. I think we're going to have to ask for QA tests (both regression
and performance) to be written as part of the patch acceptance policy -
under this policy, merely passing existing QA will not be sufficient.

I think that'll depend very much on what the change is.  For new
functionality, sounds good; for bugfixes with testcases, sounds good.

and for cleanups, just run existing QA (new test wouldn't normally make sense).

For general algorithm improvements... how do you write a new QA test for
"Use the inode tree for finding dirty inodes?"

Case by case basis I guess. e.g. write a test that exercises or stresses
the changed algorithm or functionality, especially corner cases (low
space, full AGs, mem pressure, whatever). Performance regression testing
is trickier - need access to suitable h/w and the historical data; so it's
probably best run on dedicated h/w every night against the dev tree.

Or for that matter, my
remaining 2 shouting-removal patches ;)

As above, just run QA for cleanups.

We have recently set up external access to a system for QA and
regression testing for Christoph's use .. perhaps that should
be a permanent offering?

Sounds awesome, for serious contributors.  I'd be happy to use it, too ;)



 Mark Goodwin                                  markgw@xxxxxxx
 Engineering Manager for XFS and PCP    Phone: +61-3-99631937
 SGI Australian Software Group           Cell: +61-4-18969583

<Prev in Thread] Current Thread [Next in Thread>