Re: [patch 0/3] 2.6.20 fix for PageUptodate memorder problem (try 3)
On Tue, 2007-02-13 at 06:52 +0100, Nick Piggin wrote: > Thanks for the confirmation. > > I'll obviously have to resend a new patchset because I made a silly > paper-bag bug with this one. May I say that the s390 specific part of > the change is acked-by: you? Yes. -- blue skies, Martin. Martin Schwidefsky Linux for zSeries Development & Services IBM Deutschland Entwicklung GmbH "Reality continues to ruin my life." - Calvin. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 0/3] 2.6.20 fix for PageUptodate memorder problem (try 3)
On Tue, 2007-02-13 at 06:52 +0100, Nick Piggin wrote: Thanks for the confirmation. I'll obviously have to resend a new patchset because I made a silly paper-bag bug with this one. May I say that the s390 specific part of the change is acked-by: you? Yes. -- blue skies, Martin. Martin Schwidefsky Linux for zSeries Development Services IBM Deutschland Entwicklung GmbH Reality continues to ruin my life. - Calvin. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 0/3] 2.6.20 fix for PageUptodate memorder problem (try 3)
On Sat, Feb 10, 2007 at 11:44:55PM +0100, Martin Schwidefsky wrote: > On Sat, 2007-02-10 at 03:31 +0100, Nick Piggin wrote: > > SetNewPageUptodate does not do the S390 page_test_and_clear_dirty, so > > I'd like to make sure that's OK. > > An I/O operation on s390 will set the dirty bit for a page. That is the Oh, OK. > reason to have SetPageUptodate clear the per page dirty bit when the > page is made uptodate the first time. Otherwise we end up writing each > page back to its backing device at least once. If SetNewPageUptodate is > used on new anonymous pages exclusively I don't see a problem in > omitting the page_test_clear_dirty. Thanks for the confirmation. I'll obviously have to resend a new patchset because I made a silly paper-bag bug with this one. May I say that the s390 specific part of the change is acked-by: you? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 0/3] 2.6.20 fix for PageUptodate memorder problem (try 3)
On Sat, Feb 10, 2007 at 11:44:55PM +0100, Martin Schwidefsky wrote: On Sat, 2007-02-10 at 03:31 +0100, Nick Piggin wrote: SetNewPageUptodate does not do the S390 page_test_and_clear_dirty, so I'd like to make sure that's OK. An I/O operation on s390 will set the dirty bit for a page. That is the Oh, OK. reason to have SetPageUptodate clear the per page dirty bit when the page is made uptodate the first time. Otherwise we end up writing each page back to its backing device at least once. If SetNewPageUptodate is used on new anonymous pages exclusively I don't see a problem in omitting the page_test_clear_dirty. Thanks for the confirmation. I'll obviously have to resend a new patchset because I made a silly paper-bag bug with this one. May I say that the s390 specific part of the change is acked-by: you? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 0/3] 2.6.20 fix for PageUptodate memorder problem (try 3)
On Sat, 2007-02-10 at 03:31 +0100, Nick Piggin wrote: > SetNewPageUptodate does not do the S390 page_test_and_clear_dirty, so > I'd like to make sure that's OK. An I/O operation on s390 will set the dirty bit for a page. That is the reason to have SetPageUptodate clear the per page dirty bit when the page is made uptodate the first time. Otherwise we end up writing each page back to its backing device at least once. If SetNewPageUptodate is used on new anonymous pages exclusively I don't see a problem in omitting the page_test_clear_dirty. -- blue skies, Martin. Martin Schwidefsky Linux for zSeries Development & Services IBM Deutschland Entwicklung GmbH "Reality continues to ruin my life." - Calvin. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 0/3] 2.6.20 fix for PageUptodate memorder problem (try 3)
On Sat, 2007-02-10 at 03:31 +0100, Nick Piggin wrote: SetNewPageUptodate does not do the S390 page_test_and_clear_dirty, so I'd like to make sure that's OK. An I/O operation on s390 will set the dirty bit for a page. That is the reason to have SetPageUptodate clear the per page dirty bit when the page is made uptodate the first time. Otherwise we end up writing each page back to its backing device at least once. If SetNewPageUptodate is used on new anonymous pages exclusively I don't see a problem in omitting the page_test_clear_dirty. -- blue skies, Martin. Martin Schwidefsky Linux for zSeries Development Services IBM Deutschland Entwicklung GmbH Reality continues to ruin my life. - Calvin. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 0/3] 2.6.20 fix for PageUptodate memorder problem (try 3)
OK, I have got rid of SetPageUptodate_nowarn, and removed the atomic op from SetNewPageUptodate. Made PageUptodate_NoLock only issue the memory barrier is the page was uptodate (hopefully the compiler can thread the branch into the caller's branch). SetNewPageUptodate does not do the S390 page_test_and_clear_dirty, so I'd like to make sure that's OK. Rearranged the patch series so we don't have the first patch introducing a lot of WARN_ONs that are solved in the next two patches (rather, solve those issues first). Thanks, Nick -- SuSE Labs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 0/3] 2.6.20 fix for PageUptodate memorder problem (try 3)
OK, I have got rid of SetPageUptodate_nowarn, and removed the atomic op from SetNewPageUptodate. Made PageUptodate_NoLock only issue the memory barrier is the page was uptodate (hopefully the compiler can thread the branch into the caller's branch). SetNewPageUptodate does not do the S390 page_test_and_clear_dirty, so I'd like to make sure that's OK. Rearranged the patch series so we don't have the first patch introducing a lot of WARN_ONs that are solved in the next two patches (rather, solve those issues first). Thanks, Nick -- SuSE Labs - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
