Set VE_PDMA_IO=1 to disable accelerated I/O

[veos-sxarr]

Set VE_PDMA_IO=1 to disable accelerated I/O when vh_urpc_child_create() execute aveorun.

In installation guide, we allocate 32 huge pages per VE core.
ve-urpc use 32 huge pages per peer.
Accelerated I/O also uses 32 huge pages per process.
So, we should disable accelerated I/O.

[efocht]

I don't think this is a good idea. Why should we imply that VHes have only 32 huge pages per VE? If people allocate 64 or more pages per VE then this feature can still be enabled and coexist with AVEO.

[veos-sxarr]

We want end users who use SX-Aurora TSUBASA in a computing center to use AVEO (and ve-urpc). End users can not allocate huge pages because they does not have root privilege.

If a user use AVEO with accelerated I/O, more huge pages will be used than expected. Then, other user can not use huge pages if huge pages are exhausted. So, we want to disable accelerated I/O in order to avoid such trouble.

Accelerated I/O is a feature to improve performance of read/write family system calls from VE. In case of AVEO, users will not uses such system calls from VE because the main part of application is executed on VH side. So, disabling this feature don't have much impact.

[efocht]

I understand the motivation, but I don't understand the limitation of 64MB per VE. That is a one-line comment in the manual, asking people to increase the number of huge pages if they want AVEO to coexist with accelerated I/O. Which might well be used from AVEO, after all read/write is not uncommon. You also need more than 64MB if you have two users on a machine. Or more users.

If you do this inside AVEO or VE-URPC then you take control away from the users and they can not get it back, because you decided for them that they should never use the two components together. If you advise them, then they can decide. Users or admins. I mean: you try to make it foolproof, but punish the more capable users, who are smart enough to manage the system.

I would argue for a compromise: if we can find out that the huge pages are gone after VE-URPC has started, or lie below a threshold, then we set the env variable. It would involve reading /proc/meminfo.