From: "Leizhen (ThunderTown)" <thunder.leizhen@huawei.com> To: Catalin Marinas <catalin.marinas@arm.com> Cc: Steve Capper <Steve.Capper@arm.com>, David Woods <dwoods@ezchip.com>, Tianhong Ding <dingtianhong@huawei.com>, Will Deacon <will.deacon@arm.com>, linux-kernel <linux-kernel@vger.kernel.org>, Xinwei Hu <huxinwei@huawei.com>, Zefan Li <lizefan@huawei.com>, Hanjun Guo <guohanjun@huawei.com>, linux-arm-kernel <linux-arm-kernel@lists.infradead.org> Subject: Re: [PATCH 1/1] arm64/hugetlb: clear PG_dcache_clean if the page is dirty when munmap Date: Wed, 20 Jul 2016 10:46:27 +0800 [thread overview] Message-ID: <578EE603.9020206@huawei.com> (raw) In-Reply-To: <20160712153535.GH22183@e104818-lin.cambridge.arm.com> On 2016/7/12 23:35, Catalin Marinas wrote: > On Mon, Jul 11, 2016 at 08:43:32PM +0800, Leizhen (ThunderTown) wrote: >> On 2016/7/9 0:13, Catalin Marinas wrote: >>> On Fri, Jul 08, 2016 at 11:24:26PM +0800, Leizhen (ThunderTown) wrote: >>>> On 2016/7/8 21:54, Catalin Marinas wrote: >>>>> ------------8<---------------- >>>>> diff --git a/arch/arm64/mm/flush.c b/arch/arm64/mm/flush.c >>>>> index dbd12ea8ce68..c753fa804165 100644 >>>>> --- a/arch/arm64/mm/flush.c >>>>> +++ b/arch/arm64/mm/flush.c >>>>> @@ -75,7 +75,8 @@ void __sync_icache_dcache(pte_t pte, unsigned long addr) >>>>> if (!page_mapping(page)) >>>>> return; >>>>> >>>>> - if (!test_and_set_bit(PG_dcache_clean, &page->flags)) >>>>> + if (!test_and_set_bit(PG_dcache_clean, &page->flags) || >>>>> + PageDirty(page)) >>>>> sync_icache_aliases(page_address(page), >>>>> PAGE_SIZE << compound_order(page)); >>>>> else if (icache_is_aivivt()) >>>>> ----------------8<--------------------- Hi, Catalin: Do you plan to send this patch? My colleagues told me that if our patches are quite different, it should be Signed-off-by you. I searched all Linux source code, __sync_icache_dcache is only called by set_pte_at, and some check conditions(especially pte_exec) will limit its impact. if (pte_user(pte) && pte_exec(pte) && !pte_special(pte)) __sync_icache_dcache(pte, addr); >>>>> >>>>> BTW, can you make your tests (source) available somewhere? >>>> >>>> Both cases worked well with this patch. >>> >>> Now I'm even more confused ;). IIUC, after an msync() in user space we >>> should flush the pages to disk via write_cache_pages(). This function >>> calls clear_page_dirty_for_io() after which PageDirty() is no longer >>> true. I can't tell how a subsequent mmap() can see the written pages as >>> dirty. >> >> As my tracing, both cases invoked empty function. >> >> int vfs_fsync_range(struct file *file, loff_t start, loff_t end, int datasync) >> ...... >> return file->f_op->fsync(file, start, end, datasync); >> } >> >> const struct file_operations hugetlbfs_file_operations = { >> .fsync = noop_fsync, >> >> static const struct file_operations shmem_file_operations = { >> .mmap = shmem_mmap, >> #ifdef CONFIG_TMPFS >> .fsync = noop_fsync, > > I was referring to standard filesystem (e.g. ext4) writes where, IIUC, > the PageDirty() status is cleared after I/O but it's not necessarily > removed from the page cache. >
WARNING: multiple messages have this Message-ID (diff)
From: thunder.leizhen@huawei.com (Leizhen (ThunderTown)) To: linux-arm-kernel@lists.infradead.org Subject: [PATCH 1/1] arm64/hugetlb: clear PG_dcache_clean if the page is dirty when munmap Date: Wed, 20 Jul 2016 10:46:27 +0800 [thread overview] Message-ID: <578EE603.9020206@huawei.com> (raw) In-Reply-To: <20160712153535.GH22183@e104818-lin.cambridge.arm.com> On 2016/7/12 23:35, Catalin Marinas wrote: > On Mon, Jul 11, 2016 at 08:43:32PM +0800, Leizhen (ThunderTown) wrote: >> On 2016/7/9 0:13, Catalin Marinas wrote: >>> On Fri, Jul 08, 2016 at 11:24:26PM +0800, Leizhen (ThunderTown) wrote: >>>> On 2016/7/8 21:54, Catalin Marinas wrote: >>>>> ------------8<---------------- >>>>> diff --git a/arch/arm64/mm/flush.c b/arch/arm64/mm/flush.c >>>>> index dbd12ea8ce68..c753fa804165 100644 >>>>> --- a/arch/arm64/mm/flush.c >>>>> +++ b/arch/arm64/mm/flush.c >>>>> @@ -75,7 +75,8 @@ void __sync_icache_dcache(pte_t pte, unsigned long addr) >>>>> if (!page_mapping(page)) >>>>> return; >>>>> >>>>> - if (!test_and_set_bit(PG_dcache_clean, &page->flags)) >>>>> + if (!test_and_set_bit(PG_dcache_clean, &page->flags) || >>>>> + PageDirty(page)) >>>>> sync_icache_aliases(page_address(page), >>>>> PAGE_SIZE << compound_order(page)); >>>>> else if (icache_is_aivivt()) >>>>> ----------------8<--------------------- Hi, Catalin: Do you plan to send this patch? My colleagues told me that if our patches are quite different, it should be Signed-off-by you. I searched all Linux source code, __sync_icache_dcache is only called by set_pte_at, and some check conditions(especially pte_exec) will limit its impact. if (pte_user(pte) && pte_exec(pte) && !pte_special(pte)) __sync_icache_dcache(pte, addr); >>>>> >>>>> BTW, can you make your tests (source) available somewhere? >>>> >>>> Both cases worked well with this patch. >>> >>> Now I'm even more confused ;). IIUC, after an msync() in user space we >>> should flush the pages to disk via write_cache_pages(). This function >>> calls clear_page_dirty_for_io() after which PageDirty() is no longer >>> true. I can't tell how a subsequent mmap() can see the written pages as >>> dirty. >> >> As my tracing, both cases invoked empty function. >> >> int vfs_fsync_range(struct file *file, loff_t start, loff_t end, int datasync) >> ...... >> return file->f_op->fsync(file, start, end, datasync); >> } >> >> const struct file_operations hugetlbfs_file_operations = { >> .fsync = noop_fsync, >> >> static const struct file_operations shmem_file_operations = { >> .mmap = shmem_mmap, >> #ifdef CONFIG_TMPFS >> .fsync = noop_fsync, > > I was referring to standard filesystem (e.g. ext4) writes where, IIUC, > the PageDirty() status is cleared after I/O but it's not necessarily > removed from the page cache. >
next prev parent reply other threads:[~2016-07-20 2:47 UTC|newest] Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-07-07 12:09 [PATCH 1/1] arm64/hugetlb: clear PG_dcache_clean if the page is dirty when munmap Zhen Lei 2016-07-07 12:09 ` Zhen Lei 2016-07-07 15:37 ` Catalin Marinas 2016-07-07 15:37 ` Catalin Marinas 2016-07-08 3:36 ` Leizhen (ThunderTown) 2016-07-08 3:36 ` Leizhen (ThunderTown) 2016-07-08 13:54 ` Catalin Marinas 2016-07-08 13:54 ` Catalin Marinas 2016-07-08 15:24 ` Leizhen (ThunderTown) 2016-07-08 15:24 ` Leizhen (ThunderTown) 2016-07-08 16:13 ` Catalin Marinas 2016-07-08 16:13 ` Catalin Marinas 2016-07-11 12:43 ` Leizhen (ThunderTown) 2016-07-11 12:43 ` Leizhen (ThunderTown) 2016-07-12 15:35 ` Catalin Marinas 2016-07-12 15:35 ` Catalin Marinas 2016-07-20 2:46 ` Leizhen (ThunderTown) [this message] 2016-07-20 2:46 ` Leizhen (ThunderTown) 2016-07-20 9:19 ` Catalin Marinas 2016-07-20 9:19 ` Catalin Marinas 2016-08-22 4:19 ` Leizhen (ThunderTown) 2016-08-22 4:19 ` Leizhen (ThunderTown) 2016-08-23 17:28 ` Catalin Marinas 2016-08-23 17:28 ` Catalin Marinas 2016-08-24 1:30 ` Leizhen (ThunderTown) 2016-08-24 1:30 ` Leizhen (ThunderTown) 2016-08-24 9:00 ` Leizhen (ThunderTown) 2016-08-24 9:00 ` Leizhen (ThunderTown) 2016-08-24 10:30 ` Catalin Marinas 2016-08-24 10:30 ` Catalin Marinas 2016-08-25 1:42 ` Leizhen (ThunderTown) 2016-08-25 1:42 ` Leizhen (ThunderTown) 2016-08-25 9:30 ` Catalin Marinas 2016-08-25 9:30 ` Catalin Marinas 2016-08-25 11:27 ` Leizhen (ThunderTown) 2016-08-25 11:27 ` Leizhen (ThunderTown)
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=578EE603.9020206@huawei.com \ --to=thunder.leizhen@huawei.com \ --cc=Steve.Capper@arm.com \ --cc=catalin.marinas@arm.com \ --cc=dingtianhong@huawei.com \ --cc=dwoods@ezchip.com \ --cc=guohanjun@huawei.com \ --cc=huxinwei@huawei.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=lizefan@huawei.com \ --cc=will.deacon@arm.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.