On Fri, Oct 11, 2024 at 9:32 AM Peter Xu <pet...@redhat.com> wrote: > > On Wed, Oct 09, 2024 at 04:45:58PM -0700, Yichen Wang wrote: > > The doc update is still missing under docs/, we may need that for a final > merge. >
I will work with Intel to prepare a doc in my next patch. > Are you using this in production? How it performs in real life? What is > the major issue to solve for you? Is it "zero detect eats cpu too much", > or "migration too slow", or "we're doing experiment with the new hardwares, > and see how it goes if we apply it on top of migrations"? > Yes, we do use it in production. Our codebase is based on an old QEMU release (5.X), so we backported the series there. The major use case is just to accelerate the live migration, and it is currently under QA scale testing. The main motivation is, we reserve 4 cores for all control plane services including QEMU. While doing 2nd-scheduling (i.e. live migration to reduce the fragmentations, and very commonly seen on cloud providers), we realize QEMU will eat a lot of CPUs which causes jitter and slowness on the control planes. Even though this is not happening too frequently, we still want it to be stable. With the help of DSA, it saves CPU while accelerates the process, so we want to use it in production. > There're a lot of new code added for dsa just for this optimization on zero > page detection. We'd better understand the major benefits, and also > whether that's applicable to other part of qemu or migration-only. I > actually wonder if we're going to support enqcmd whether migration is the > best starting point (rather than other places where we emulate tons of > devices, and maybe some backends can speedup IOs with enqcmd in some > form?).. but it's more of a pure question. > I tried to put most of the code in dsa.c and do minimum changes on all other files. Even in dsa.c, it has the abstraction for "submit task", and the implementation of "submit a buffer_zero task". I think this is the best I can think of. I am open to suggestions of how we can help to move this forward. :) > Thanks, > > -- > Peter Xu >
