v6 Add TrIO support in EROFS · Pull Request !15320 · openEuler/kernel

PR sync from: Hongbo Li <lihongbo22@huawei.com>
https://mailweb.openeuler.org/archives/list/kernel@openeuler.org/message/FCR4MLKCDYZQ6TQPK5655WSGUIO5E2OJ/ 
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.

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

GVPopenEuler/kernel

搜索帮助

GVP openEuler/kernel