[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 IO > (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. Simon _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |