lkml.org 
[lkml]   [2002]   [Nov]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] flush_cache_page while pte valid
>
>
>>
>> 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 TLB
try_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 tlb
flush_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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:30    [W:0.048 / U:0.156 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site