[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-devel] Re: Reducing impact of save/restore/dump on Dom0

> > It's pretty easy for us to arrange that everything is page aligned.
> If
> > there was a measurable performance advantage using o_direct rather
> than
> > madvise/fadvise it probably makes sense to use it -- I can't see
> > o_direct going away any time soon.
> O_DIRECT won't do any write behind, so unless you do very aggressive
> (large IO requests, threads or aio so you do useful work during the
> disk write
> latency) it will be likely slower. Similar for read -- it won't do any
> readahead which you would need to do by yourself.
> It's really not a very good idea for most non database applications.

Well, the dump/save/restore does do large IO requests for most of the
data. Also, it's a non-performance path - it's MUCH more important that
other things in Dom0 happen quickly (such as performing I/O for other
domains) so I would be quite happy with the save/restore/dump process
being a little slow in return for not destroying Dom0 performance (which
is what happens today).

Having said that, I understand that O_DIRECT is deprecated (by Linus at
least) and there is also the problem of it not being available on
Solaris; hence I am trying out the fsync/fadvise(DON'T_NEED) in the loop
after writing/reading a chunk of data.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.