On 2018/11/2 上午12:20, Andrey Repin wrote: > Greetings, kemi! > >> Yes. Using unprivileged container is a workaround, not very good though. > > You're confusing containerization with virtualization.
Maybe. I am not familiar with containerization. > Container not supposed to have direct access to devices on the host. > It provides a ready system for **userspace** applications to run. > Said that, what kind of hundreds of containers your customer wants to run > which require access to host hardware? > > thx for your question. In our case, our customers want to run android games within containers on cloud. There are two problems we have known. The first one occurs during Android OS boot, the coldboot of Android requires to write uevent file in /sys, this will trigger an uevent broadcast to all of listeners (udev daemons) in user space (this uevent is sent from kernel via netlink), with the increase of container number (200+), we found the boot latency has reached 1~2 mins. And latency would be intolerable when the number reaches 500. The second one occurs when an app in container begins to run, it will read /sys/devices/system/cpu/online file to get avilable cpu number before creating threads accordingly. Then. the problem is, sysfs now is shared with host, it will get the CPU number equals to host thread number even if the cpu number of container is limited. _______________________________________________ lxc-users mailing list lxc-users@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-users
