+11
−0
+1
−0
+21
−1
Loading
Merge Pull Request from: @ci-robot PR sync from: Hongbo Li <lihongbo22@huawei.com> https://mailweb.openeuler.org/archives/list/kernel@openeuler.org/message/NMI47HY3T7HXK4PJXMRX54DCPVTZISWD/ TrIO can accelerate the cold start of containers during on-demand loading. It aggregates the read I/O operations required for container runtime during the first container launch. In the following startups, TrIO pulls the necessary I/O data to the container node in a single large I/O operation and uses this I/O information to construct the runtime rootfs. By improving the efficiency of network I/O, TrIO speeds up container startup in on-demand loading scenarios. TrIO consists of both kernel-space and user-space code. The kernel-space code has been adapted at the overlayfs layer, introducing the CONFIG_EROFS_TRIO configuration to provide isolation. The user-space code requires adaptation by the user, and detailed usage methods are introduced in the tools/trio/README.md section. Patches 1~2 correspond to the kernel adaptations, while patches 3~4 are the scripts and best practices that TrIO relies on for its operation. v6: - Add folio_put after filemap_get_folio. - Filter trace with lowerdir v5: - Adapt to the large folio tracepoint in erofs. - Adapt to the multiple type of page size (4k and 64k). v4: - Avoid the memleak of meta_buf. - Fix some exception handle from reviewer's suggestions. - Use spinlock in kprobe context. v3: - Obtain and keep the trio_object in open. - Only close readahead in trio case. Hongbo Li (4): erofs:trio: Add trio_manager in erofs erofs: trio: Support TrIO feature in erofs TrIO: Add tools for using TrIO TrIO: Add README.md https://gitee.com/openeuler/release-management/issues/IBK2MJ Link:https://gitee.com/openeuler/kernel/pulls/15323 Reviewed-by:zhangyi (F) <yi.zhang@huawei.com> Reviewed-by:
Hou Tao <houtao1@huawei.com> Signed-off-by:
Zhang Peng <zhangpeng362@huawei.com>