[Lustre-devel] Oleg/Mike Work on Apps Metrics - FW: Mike Booth week ending 2009.03.15
di wang
di.wang at sun.com
Mon Apr 6 15:12:30 PDT 2009
Hello,
Andreas Dilger wrote:
> I'm not sure what you mean. Implementing AIO is _more_ complex for the
> application, and in essence the current IO is mostly async except when
> the client hits the max dirty limit. The client will still flush the
> dirty data in the background (despite Michaels experiment), it just takes
> the VM some time to catch up.
>
> Linux VM /proc tunables can be tweaked on the client to have it be more
> aggressive about pushing out dirty data. I suspect they are currently
> tuned for desktop workloads more than IO-intensive workloads.
>
>
>
I am not sure the current IO is "async" enough, since it still includes
some sync "process", for example,
locks, read for partial page, some other stack overhead in commit_write,
sometimes you can not ignore
these overhead. For example, even without hit the dirty max limit, you
might get quite different write time
for writing same data. I guess some of the reason might be the VM is
just "out of control".
With AIO,
1) The application can skip these "sync" process? For example by
creating an daemon to do the those routine process.
2) We can control the write_page(sent to OST) ourselves, instead of rely
on VM.
3) These aio pages do not need comply the dirty max limit in the
submit_io(AIO) process,
So user application do "real" memory for writing.
Yes, AIO will be indeed complex for the application, but not that much,
IMHO.
Thanks
Wangdi
>
>
More information about the lustre-devel
mailing list