Hi Jeff.
>
>I agree with the patch (and I see Andrew already accepted it). Do you
>have a reproducer for this problem?
Do you want to know the way of failing invalidate_complete_page2() ?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Hi Jeff.
I agree with the patch (and I see Andrew already accepted it). Do you
have a reproducer for this problem?
Do you want to know the way of failing invalidate_complete_page2() ?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL
if invalidate_complete_page2() fails on
some pages.
This can cause inconsistency between memory and blocks on HDD because the page
cache still exists.
Following patch fixes this issue.
Thanks.
Signed-off-by :Hisashi Hifumi <[EMAIL PROTECTED]>
diff -Nrup linux-2.6.25-rc1.org/mm/truncate.c linux-2.6.25-
if invalidate_complete_page2() fails on
some pages.
This can cause inconsistency between memory and blocks on HDD because the page
cache still exists.
Following patch fixes this issue.
Thanks.
Signed-off-by :Hisashi Hifumi [EMAIL PROTECTED]
diff -Nrup linux-2.6.25-rc1.org/mm/truncate.c linux-2.6.25-rc1/mm
At 04:15 07/12/15, Zach Brown wrote:
>
>> If anyone has a testcase - I can take a look at the problem again.
>
>I can try and throw something together..
>
>- z
I did a test by using fsstress.
I modified the dio write() of fsstress to check return value, and input
following command;
# fsstress
At 04:15 07/12/15, Zach Brown wrote:
If anyone has a testcase - I can take a look at the problem again.
I can try and throw something together..
- z
I did a test by using fsstress.
I modified the dio write() of fsstress to check return value, and input
following command;
# fsstress -d
if invalidate_complete_page2() fails
on some pages.
This can cause inconsistency between memory and blocks on HDD because the page
cache still exists.
Following patch fixes this issue.
Thanks.
Signed-off-by :Hisashi Hifumi <[EMAIL PROTECTED]>
diff -Nrup linux-2.6.24-rc5.org/mm/truncate.c linux-2.6.24-
if invalidate_complete_page2() fails
on some pages.
This can cause inconsistency between memory and blocks on HDD because the page
cache still exists.
Following patch fixes this issue.
Thanks.
Signed-off-by :Hisashi Hifumi [EMAIL PROTECTED]
diff -Nrup linux-2.6.24-rc5.org/mm/truncate.c linux-2.6.24-rc5/mm
>
>>
>> Past discussion about this issue is as follows.
>> http://marc.info/?t=11934343124=1=2
>> http://marc.info/?t=11265676282=1=2
>>
>> 2, invalidate_inode_pages2_range() sets ret=-EIO when
>> invalidate_complete_page2()
>> fails, but this ret is cleared if do_launder_page() succeed
Past discussion about this issue is as follows.
http://marc.info/?t=11934343124r=1w=2
http://marc.info/?t=11265676282r=1w=2
2, invalidate_inode_pages2_range() sets ret=-EIO when
invalidate_complete_page2()
fails, but this ret is cleared if do_launder_page() succeed on a page of
that should be
acquired again is smaller.
Thanks.
Signed-off-by :Hisashi Hifumi <[EMAIL PROTECTED]>
diff -Nrup linux-2.6.24-rc4.org/include/linux/fs.h
linux-2.6.24-rc4/include/linux/fs.h
--- linux-2.6.24-rc4.org/include/linux/fs.h 2007-12-06 12:05:30.0
+0900
+++ linux-2.6.
page that should be
acquired again is smaller.
Thanks.
Signed-off-by :Hisashi Hifumi [EMAIL PROTECTED]
diff -Nrup linux-2.6.24-rc4.org/include/linux/fs.h
linux-2.6.24-rc4/include/linux/fs.h
--- linux-2.6.24-rc4.org/include/linux/fs.h 2007-12-06 12:05:30.0
+0900
+++ linux-2.6.24-rc4
17.314/0.091 ms
The influence to response was small.
Thanks.
Signed-off-by :Hisashi Hifumi <[EMAIL PROTECTED]>
diff -Nrup linux-2.6.23-rc6.org/include/linux/swap.h
linux-2.6.23-rc6/include/linux/swap.h
--- linux-2.6.23-rc6.org/include/linux/swap.h 2007-09-14 16:49:57.0
+0900
The influence to response was small.
Thanks.
Signed-off-by :Hisashi Hifumi [EMAIL PROTECTED]
diff -Nrup linux-2.6.23-rc6.org/include/linux/swap.h
linux-2.6.23-rc6/include/linux/swap.h
--- linux-2.6.23-rc6.org/include/linux/swap.h 2007-09-14 16:49:57.0
+0900
+++ linux-2.6.23-rc6/include
Thank you for your comment.
At 11:37 07/09/14, Andrew Morton wrote:
>The page_count() test here is a bit of a worry, too. Why do we need it?
>The caller must have pinned the page in some fashion else we couldn't use
>it safely in this function at all.
>
>I assume that you discovered that once
Thank you for your comment.
At 11:37 07/09/14, Andrew Morton wrote:
The page_count() test here is a bit of a worry, too. Why do we need it?
The caller must have pinned the page in some fashion else we couldn't use
it safely in this function at all.
I assume that you discovered that once we've
17.314/0.091 ms
Max round-trip-time was improved.
The test machine spec is that 4CPU(3.16GHz, Hyper-threading enabled)
8GB memory , 8GB swap.
Thanks.
Signed-off-by :Hisashi Hifumi <[EMAIL PROTECTED]>
diff -Nrup linux-2.6.23-rc5.org/include/linux/swap.h
linux-2.6.23-rc5/include/linux/
17.314/0.091 ms
Max round-trip-time was improved.
The test machine spec is that 4CPU(3.16GHz, Hyper-threading enabled)
8GB memory , 8GB swap.
Thanks.
Signed-off-by :Hisashi Hifumi [EMAIL PROTECTED]
diff -Nrup linux-2.6.23-rc5.org/include/linux/swap.h
linux-2.6.23-rc5/include/linux/swap.h
At 11:47 07/04/24, Nick Piggin wrote:
>As Hugh points out, we must have atomic ops here, so changing the generic
>code to use the __ version is wrong. However if there is a faster way that
>i386 can perform the atomic variant, then doing so will speed up the generic
>code without breaking other
At 11:47 07/04/24, Nick Piggin wrote:
As Hugh points out, we must have atomic ops here, so changing the generic
code to use the __ version is wrong. However if there is a faster way that
i386 can perform the atomic variant, then doing so will speed up the generic
code without breaking other
At 22:42 07/04/23, Hugh Dickins wrote:
>On Mon, 23 Apr 2007, Hisashi Hifumi wrote:
>> >No. The PG_lru flag bit is just one bit amongst many others:
>> >what of concurrent operations changing other bits in that same
>> >unsigned long e.g. trying to lock
>No. The PG_lru flag bit is just one bit amongst many others:
>what of concurrent operations changing other bits in that same
>unsigned long e.g. trying to lock the page by setting PG_locked?
>There are some places where such micro-optimizations can be made
>(typically while first allocating
Hi
PageLRU flag operation is protected by zone->lru_lock, so
SetPageLRU/ClearPageLRU
can be replaced to __SetPageLRU/__ClearPageLRU non-atomic bit operation.
Thanks.
Signed-off-by :Hisashi Hifumi <[EMAIL PROTECTED]>
diff -Nrup linux-2.6.21-rc7.org/include/linux/page-flags.h
linux-2
Hi
PageLRU flag operation is protected by zone-lru_lock, so
SetPageLRU/ClearPageLRU
can be replaced to __SetPageLRU/__ClearPageLRU non-atomic bit operation.
Thanks.
Signed-off-by :Hisashi Hifumi [EMAIL PROTECTED]
diff -Nrup linux-2.6.21-rc7.org/include/linux/page-flags.h
linux-2.6.21-rc7
No. The PG_lru flag bit is just one bit amongst many others:
what of concurrent operations changing other bits in that same
unsigned long e.g. trying to lock the page by setting PG_locked?
There are some places where such micro-optimizations can be made
(typically while first allocating the
At 22:42 07/04/23, Hugh Dickins wrote:
On Mon, 23 Apr 2007, Hisashi Hifumi wrote:
No. The PG_lru flag bit is just one bit amongst many others:
what of concurrent operations changing other bits in that same
unsigned long e.g. trying to lock the page by setting PG_locked?
There are some
IRQ is already disabled through local_irq_disable().
So spin_lock_irqsave() can be replaced with spin_lock().
Thanks.
Signed-off-by :Hisashi Hifumi <[EMAIL PROTECTED]>
--- linux-2.6.21-rc5.org/arch/i386/kernel/reboot.c 2007-02-05
03:44:54.0 +0900
+++ linux-2.6.21-rc5-test/arc
IRQ is already disabled through local_irq_disable().
So spin_lock_irqsave() can be replaced with spin_lock().
Thanks.
Signed-off-by :Hisashi Hifumi [EMAIL PROTECTED]
--- linux-2.6.21-rc5.org/arch/i386/kernel/reboot.c 2007-02-05
03:44:54.0 +0900
+++ linux-2.6.21-rc5-test/arch/i386
28 matches
Mail list logo
