Re: [PATCH v3 5/6] eal/linux: allow hugepage file reuse

["Burakov, Anatoly" <anatoly.burakov@intel.com>]

On 03-Feb-22 6:13 PM, Dmitry Kozlyuk wrote:
> Linux EAL ensured that mapped hugepages are clean
> by always mapping from newly created files:
> existing hugepage backing files were always removed.
> In this case, the kernel clears the page to prevent data leaks,
> because the mapped memory may contain leftover data
> from the previous process that was using this memory.
> Clearing takes the bulk of the time spent in mmap(2),
> increasing EAL initialization time.
> 
> Introduce a mode to keep existing files and reuse them
> in order to speed up initial memory allocation in EAL.
> Hugepages mapped from such files may contain data
> left by the previous process that used this memory,
> so RTE_MEMSEG_FLAG_DIRTY is set for their segments.
> If multiple hugepages are mapped from the same file:
> 1. When fallocate(2) is used, all memory mapped from this file
>     is considered dirty, because it is unknown
>     which parts of the file are holes.
> 2. When ftruncate(3) is used, memory mapped from this file
>     is considered dirty unless the file is extended
>     to create a new mapping, which implies clean memory.
> 
> Signed-off-by: Dmitry Kozlyuk <dkozlyuk@nvidia.com>
> ---


> -	while(dirent != NULL){
> +	while (dirent != NULL) {
>   		/* skip files that don't match the hugepage pattern */
>   		if (fnmatch(filter, dirent->d_name, 0) > 0) {
>   			dirent = readdir(dir);
> @@ -345,9 +357,15 @@ clear_hugedir(const char * hugedir)
>   		/* non-blocking lock */
>   		lck_result = flock(fd, LOCK_EX | LOCK_NB);
>   
> -		/* if lock succeeds, remove the file */
> +		/* if lock succeeds, execute callback */
>   		if (lck_result != -1)
> -			unlinkat(dir_fd, dirent->d_name, 0);
> +			cb(&(struct walk_hugedir_data){
> +				.dir_fd = dir_fd,
> +				.file_fd = fd,
> +				.file_name = dirent->d_name,
> +				.user_data = user_data,
> +			});

Off topic, but nice trick! Didn't know C allowed for this.

Otherwise, LGTM

Reviewed-by: Anatoly Burakov <anatoly.burakov@intel.com>
-- 
Thanks,
Anatoly