flush_cache_page while pte valid
Quoted 10 lines
Quoted 6 lines
The flush merely writes back the data, a copy-back operation, fully L2 cache coherent. All cpus will see correct data if an intermittant store occurs.
The CPUs will, but the harddisk might not.
The lost dirty bit can only happen on cpus where the hardware maintains a dirty bit. I doubt that the sparc cpus do that in hardware.
But like Hugh I don't understand how the cache writeback works on SMP.
cpu1: cpu 2
access a mmaping, pte loaded into TLBtry_to_unmap_one()flush_cache_page();
access the mmaping again. pte either still from tlb, or reloaded from pte.ptep_get_and_clear();
access the mmaping again, using the tlbflush_tlb()
??? How will the cpu write back now?
If the write back happens based on the tlb, then I don't understand why it's needed at all.
Regarding the dirty bit:
The assumption for the dirty bit is that the i386 cpu are the only cpus in the world (TM) that maintain the dirty bit in hardware, and tests on several i386 cpus have shown that the tlb walker retests the present bit before setting the dirty bit. Software tlb implementations must emulate that.
Thus it's guaranteed that
- if the dirty bit is not set in the result of ptep_get_and_clear, then no write operation has happened or will happen.
- if the dirty bit is set, then write operations could happen until the tlb flush.
- there will be no spuriously set dirty bits in the page tables.
--
Manfred
From: Manfred Spraul <[email protected]>
Date: Tue, 12 Nov 2002 21:53:14 +0100
The lost dirty bit can only happen on cpus where the hardware maintains a dirty bit. I doubt that the sparc cpus do that in hardware.
sun4m sparc32 chips do, exactly like x86
Franks a lot,
David S. Miller
[email protected]