[ros-kernel] AW: Re: making vfat asynchronous

[Hartmut B. <har...@te...>]

> This is just not true.  A higher level driver that context switches to
> another thread only to have it block until IO completion is just as nasty 

> of a kludge as a lower level driver that constantly busy waits until it's 

> device is done, rather than waiting for the device to interrupt.  The 
whole
> idea behind async IO is that a program can request the IO, the FSD tells
> the device driver to request the IO, and the device driver tells the
> hardware to start the IO, and returns back to the calling program which 
can
> then do other work while the IO is in progress.  The device can then
> interrupt, and then IO be completed back to the calling program, all
> without a single context switch, as long as the calling program has 
enough
> other work to keep it busy while the IO is going on, and if it doesn't 
have
> any more work to do, then switching to the idle thread isn't wasting any
> cycles that could be better used anyhow.  By the way, an ISR and DPC is 
not
> a context switch, at least in NT terminology.  Switching threads is far
> more costly than handling an interrupt or calling a DPC in
> KeLowerIrql().  NT and all other decent kernels that support async IO do 
it
> this way, and so should we.

For asynchronous i/o the FSD can't only queued up to request to the 
underlaying driver. At some points, the FSD must synchronisize the access 
to some internal structures. With which other functions as a thread can the 
FSD wait for acquireing a synchronisation object, such a ersource? At the 
moment, vfat ask for acquireing the eresource and when the caller can't 
wait for completion of the request, vfat queue the request as a thread to 
the system worker queue. The thread wait for acquireing the eresource 
object. I doesn't know an other function, that can do this.

> >The current cache manger can only handle small memory segments. This
> >results in many calls to the fsd, when there is a read or write with 
large
> >datas, which are not in the cache. The cooperation betwen the cache and 
the
> >memory manger isn't good. Each missing page results in a single call to 
the
> >fsd for 4K page. The cache manager has no read ahead or delayed write
> >function. But this is not only the problem of the cache or memory 
manger.
> >Vfatfs must also provide some functions for the cache manager.
>
> I see.  So you think we need to implement the cache manager the NT way 
then?

An other way is, that the chache manger add/merge the pages from some cache 
segments within one mdl and then call the FSD with this large mdl for a 
paging io. For paging io as a result from page faults in section views, the 
memory manger should read and map more then one page.

====================================================
= To remove yourself from this mailing list, go to =
= http://www.reactos.com/home/mailing.html         =
====================================================