> Still I have not slightest clue what 8EB means or is about.
8 exabytes…
Anton Bassov
> When a page is being written out to disk, any other process that faults
on it will wait for the I/O to complete. Actually, this applies to read
operations as well.
For read operations Mm can sometimes issue more than one IO
for the same page. This is called a “flow-through collided fault”
and is used for example when a thread running at low IO priority
faults on a page, and then a normal priority thread faults on the
same page.
–
This posting is provided “AS IS” with no warranties, and confers no
rights.
> For read operations Mm can sometimes issue more than one IO for the same page.
Doest not it mark the page in question as being in a transition stage??? For example, it could base its judgement of whether it should issue IRPor wait (because someone else has already did it) by means of simple test-and-set -if not successfull, wait;otherwise, issue an IRP…
Anton Bassov
>> For read operations Mm can sometimes issue more than one IO for the same
> page.
Doest not it mark the page in question as being in a transition stage???
For example, it could base its judgement of whether it should issue IRPor
wait (because someone else has already did it) by means of simple
test-and-set -if not successfull, wait;otherwise, issue an IRP…
That’s basically how things work most of the time. Collided faults typically
just wait for the original IO to complete. In some cases however waiting
for the original IO is undesirable. For example, on Vista and later it could
result in priority inversion where a thread running at normal IO priority
would get blocked for a long time waiting for the original low priority IO
to complete.
On a checked build you can look at nt!micollidedfault* counters to see
how many collided faults you have and how many of those resulted in
flow-through IOs.
–
This posting is provided “AS IS” with no warranties, and confers no
rights.
> In some cases however waiting for the original IO is undesirable.
In such case there you have to load data from the disk in the first available page, and when it gets done, check PTE and see whether someone else had already done the same thing earlier that you did (if this is the case, you have to discard the second page and return from page fault handler). In other words, you have to send multiple IRPs, and make use of the one that gets completed first. Apparently, it makes sense to do so only if failing thread is of real-time priority -otherwise, sending multiple IRPs in order to handle a single page fault seems to be a waste of time and resources…
For example, on Vista and later it could result in priority inversion where a thread running at normal IO >priority would get blocked for a long time waiting for the original low priority IO to complete.
Well, I believe it may happen on any OS that relies upon preemptive kernel and not only on Vista, don’t you think???
Anton Bassov
>> For example, on Vista and later it could result in priority inversion
> where a thread running at normal IO priority would get blocked for
> a long time waiting for the original low priority IO to complete.Well, I believe it may happen on any OS that relies upon preemptive
kernel and not only on Vista, don’t you think???
Vista is the first Windows version that has a concept of IO priority
for threads:
http://download.microsoft.com/download/a/f/7/af7777e5-7dcd-4800-8a0a-b18336565f5b/Priorityio.doc
Issuing multiple IOs (all but one of which will eventually be discarded)
is not optimal, but this happens rarely enough that it shouldn’t matter in
practice. And the alternative (waiting for the original IO to finish) can
cause rare but annoying UI freezes when an interactive app faults on
a page that is already being faulted in by some low-priority background
task (especially if something else is also hitting the disk with lots of
regular priority IO).
Another alternative would be to somehow boost the priority of the
original IO when a higher priority thread collides with it. I don’t think
Vista supports this however, and it’s not clear that adding this extra
complexity for a rather uncommon scenario would be worth it.
–
This posting is provided “AS IS” with no warranties, and confers no
rights.
Hi,
Is the code path discussed in this post always immune to transactions
rollback on vista, ie. only committed requests reach low level fs io?
and what about cancelled io ? and cancelled io and tx rollback ? and
cancelled io/tx rollback and a power event ?
thx,
Jerome.
“Pavel Lebedinsky” wrote in message news:xxxxx@ntfsd…
>>> For example, on Vista and later it could result in priority inversion
>>> where a thread running at normal IO priority would get blocked for
>>> a long time waiting for the original low priority IO to complete.
>>
>> Well, I believe it may happen on any OS that relies upon preemptive
>> kernel and not only on Vista, don’t you think???
>
>
> Vista is the first Windows version that has a concept of IO priority
> for threads:
>
> http://download.microsoft.com/download/a/f/7/af7777e5-7dcd-4800-8a0a-b18336565f5b/Priorityio.doc
>
> Issuing multiple IOs (all but one of which will eventually be discarded)
> is not optimal, but this happens rarely enough that it shouldn’t matter in
> practice. And the alternative (waiting for the original IO to finish) can
> cause rare but annoying UI freezes when an interactive app faults on
> a page that is already being faulted in by some low-priority background
> task (especially if something else is also hitting the disk with lots of
> regular priority IO).
>
> Another alternative would be to somehow boost the priority of the
> original IO when a higher priority thread collides with it. I don’t think
> Vista supports this however, and it’s not clear that adding this extra
> complexity for a rather uncommon scenario would be worth it.
>
> –
> This posting is provided “AS IS” with no warranties, and confers no
> rights.
>
>