KAMEZAWA Hiroyuki wrote:
On Thu, 05 Jul 2007 12:04:23 +1000
Nick Piggin <[email protected]> wrote:
In my understanding :
PG_arch_1 is used for showing "there is no inconsistent data on any level of
cache". PG_uptodate is used for showing "this page includes the newest data
and contents are valid."
...maybe not used for the same purpose.
I think that's right, but why is set_pte-time the critical point for the
flush? It is actually possible to write into an executable page via the
dcache *after* it has ptes pointing to it.
yes. I think there are 2 cases.
- copy-on-write case..... OS handles this.
- page is writable and app just rewrites it ...... the app should handle this.
Well it may not be "the" app, but any app on the system might write to
a page shared by any other app. OK we could just add the vague qualifier
about "don't do stupid stuff", but that should be only AFTER it is
determined that handling the corner cases is too hard.
From what I can work out, it is something like "at this point the page
should be uptodate, so at least the icache won't contain *inconsistent*
data, just old data which userspace should take care of flushing if it
modifies". Is that always true?
I think it's true. But, in this case, i-cache doesn't contain *incositent* data.
There are inconsistency between L2-Dcache and L3-mixed-cache. At L2-icache-miss,
a cpu fetches data from L3 cache.
This case seems defficult to be generalized...
If there is something in the icache line that isn't the last data to
be stored at that address, isn't that inconsistent?
Could the page get modified by means
other than a direct write(2)? And even in the case of a write(2) writer,
how do they know if another process is mapping that particular page for
exec at that time? Should they always flush? Flushing would require they
have a virtual address on the page to begin with anyway, doesn't it? So
they'd have to mmap it... phew.
I guess it is mostly safe because it is probably very uncommon to do
such a thing, and chances are no non-write(2) write activity happens to
a page after it is brought uptodate. But I don't know if that has been
audited. I would really like to see the kernel always manage all aspects
of its pagecache though. I realise performance considerations may make
this not always possible... but it might be possible to do efficiently
using mapcount these days?
generic_file_write() does flush_dcahe_page() but no flush_icache_page()...
Then..maybe this will be necessary...
==
flush_dcache_page(page);
if (page_mapcount(page) > 0 && page_is_mapped_as_text(page))
flush_icache_page(page);
==
But I don't know whether write(2) to mapped text file is expected to work well.
The point of the flush_dcache is that you have just written to dcache via
the kernel virtual address and need to handle any aliases. So if you did
want to handle this with ia64, you would do it all in flush_dcache_page.
flush_icache_page AFAIKS allows you to attempt some funny tricks to avoid
flushing @ flush_dcache_page-time. It is better than the lazy_mmu_update
thingy (because it is actually done in the right place -- ie. *before* the
set_pte), however it is still pretty tricky.
--
SUSE Labs, Novell Inc.
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
