[CRIU] aio_estimate_nr_reqs() pretends it knows too much about the kernel internals

[Pavel Emelyanov]

On 04/20/2015 08:07 PM, Oleg Nesterov wrote:
> On 04/20, Pavel Emelyanov wrote:
>>
>> On 04/16/2015 06:28 PM, Oleg Nesterov wrote:
>>>
>>> And it mostly works. But on my my testing machine running v3.10 kernel.
>>> Because it doesn't do "nr_reqs *= 2" mentioned above and thus (depending
>>> on initial nr_events passed to sys_io_setup) "criu restore" can succeed
>>> or fail.
>>>
>>> This is "fixed" by the
>>>
>>> 	-	return (k_max_reqs - 2) / 2;
>>> 	+	return k_max_reqs - 2;
>>>
>>> but somehow I am not sure you will accept this change if I send it to
>>> criu at openvz.org ;)
>>>
>>> Any idea how we can improve this "estimate" logic?
>>
>> I planned to use the convergence method :) When restoring we should create
>> context for the "best estimate" and compare the resulted length. If equal,
>> then we're done, if not -- halve/double the nr_reqs and try again.
> 
> I thought about this too. But again, this can't work if a 4096 CPU's machine
> insists on the "large" ->nr_req. You simply can not create the AIO mapping
> with the same length/nr_req in general.

Sure. And this is live migration task to check this inability. CPU incompatibilities
are checked with dump-cpuinfo/check-cpuinfo. We will also need to check this and
probably more stuff, but not in cpuifo. Oh, well...

>> Agree as the first approximation. In stead of pr_warn() we probably should
>> do destroy context and goto again with halved nr_reqs.
> 
> OK... but see above, we can't assume that we always can re-create vma with
> the same nr_reqs/length.
> 
> And if length grows, "restore" can obviously fail later.
> 
> All I can say is that io_setup() is a very nice API. I was also thinking
> about the (kernel) patch below (to avoid mremap), but I am sure it will
> be nacked. At least I would nack it if I were a maintainer ;)

:) It doesn't solve the length issue also.

-- Pavel