Linus Torvalds wrote:
> It _could_ be that the TLB data actually also contains the pointer to
> the place where it was fetched, and a "mark dirty" becomes
>
> read *ptr locked
> val |= D
> write *ptr unlock
If you want to take it really far, it _could_ be that the TLB data
contains both the pointer and the original pte contents. Then "mark
dirty" becomes
val |= D
write *ptr
> Now, I will agree that I suspect most x86 _implementations_ will not do
> this. TLB's are too timing-critical, and nobody tends to want to make
> them bigger than necessary - so saving off the source address is
> unlikely.
Then again, these hypothetical addresses etc. aren't part of the
associative lookup, so could be located in something like an ordinary
cache ram, with just an index in the TLB itself.
-- Jamie
-
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/
