* Peter Xu (pet...@redhat.com) wrote: > On Tue, Feb 22, 2022 at 10:52:23AM +0000, Dr. David Alan Gilbert wrote: > > This does get a bit complicated, which worries me a bit; the code here > > is already quite complicated. > > Right, it's the way I chose in this patchset on solving this problem. Not > sure whether there's any better and easier way. > > For example, we could have used a new thread to send requested pages, and > synchronize it with the main thread. But that'll need other kind of > complexity, and I can't quickly tell whether that'll be better. > > For this single patch, more than half of the complexity comes from the > ability to interrupt sending one huge page half-way. It's a bit of a pity > that, that part will be noop ultimately when with doublemap.
How does that huge-page interruption interact with recovery? i.e. do we know the start of that hugepage arrived? > > However I kept those only because we don't know when doublemap will be > ready, not to say, landing. Meanwhile we can't assume all kernels will > have doublemap even in the future. Yeh, if doublemap was already here you could make it a condition of allowing you to set the option. Dave > > (If you repost, there are a few 'channel' variables that could probably > > be 'unsigned' rather than int) > > That I can do for sure. > > > > > Reviewed-by: Dr. David Alan Gilbert <dgilb...@redhat.com> > > Thanks, > > -- > Peter Xu > -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
