Re: [PATCH net-next v13 01/14] mm: page_frag: add a test module for page_frag

Re: [PATCH net-next v13 01/14] mm: page_frag: add a test module for page_frag

[Muhammad Usama Anjum]

On 8/8/24 5:37 PM, Yunsheng Lin wrote:
> The testing is done by ensuring that the fragment allocated
> from a frag_frag_cache instance is pushed into a ptr_ring
> instance in a kthread binded to a specified cpu, and a kthread
> binded to a specified cpu will pop the fragment from the
> ptr_ring and free the fragment.
> 
> CC: Alexander Duyck <alexander.duyck@gmail.com>
> Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
> ---
>  tools/testing/selftests/mm/Makefile           |   2 +
>  tools/testing/selftests/mm/page_frag/Makefile |  18 ++
>  .../selftests/mm/page_frag/page_frag_test.c   | 170 ++++++++++++++++++
Why are you adding a test module in kselftests? Have you considered
adding Kunit instead? Kunit is more suited to test kernel's internal
APIs which aren't exposed to userspace.

>  tools/testing/selftests/mm/run_vmtests.sh     |   9 +-
>  4 files changed, 198 insertions(+), 1 deletion(-)
>  create mode 100644 tools/testing/selftests/mm/page_frag/Makefile
>  create mode 100644 tools/testing/selftests/mm/page_frag/page_frag_test.c
> 
> diff --git a/tools/testing/selftests/mm/Makefile b/tools/testing/selftests/mm/Makefile
> index 901e0d07765b..e91ed29378fc 100644
> --- a/tools/testing/selftests/mm/Makefile
> +++ b/tools/testing/selftests/mm/Makefile
> @@ -36,6 +36,8 @@ MAKEFLAGS += --no-builtin-rules
>  CFLAGS = -Wall -I $(top_srcdir) $(EXTRA_CFLAGS) $(KHDR_INCLUDES) $(TOOLS_INCLUDES)
>  LDLIBS = -lrt -lpthread -lm
>  
> +TEST_GEN_MODS_DIR := page_frag
> +
>  TEST_GEN_FILES = cow
>  TEST_GEN_FILES += compaction_test
>  TEST_GEN_FILES += gup_longterm
> diff --git a/tools/testing/selftests/mm/page_frag/Makefile b/tools/testing/selftests/mm/page_frag/Makefile
> new file mode 100644
> index 000000000000..58dda74d50a3
> --- /dev/null
> +++ b/tools/testing/selftests/mm/page_frag/Makefile
> @@ -0,0 +1,18 @@
> +PAGE_FRAG_TEST_DIR := $(realpath $(dir $(abspath $(lastword $(MAKEFILE_LIST)))))
> +KDIR ?= $(abspath $(PAGE_FRAG_TEST_DIR)/../../../../..)
> +
> +ifeq ($(V),1)
> +Q =
> +else
> +Q = @
> +endif
> +
> +MODULES = page_frag_test.ko
> +
> +obj-m += page_frag_test.o
> +
> +all:
> +	+$(Q)make -C $(KDIR) M=$(PAGE_FRAG_TEST_DIR) modules
> +
> +clean:
> +	+$(Q)make -C $(KDIR) M=$(PAGE_FRAG_TEST_DIR) clean
> diff --git a/tools/testing/selftests/mm/page_frag/page_frag_test.c b/tools/testing/selftests/mm/page_frag/page_frag_test.c
> new file mode 100644
> index 000000000000..0e803db1ad79
> --- /dev/null
> +++ b/tools/testing/selftests/mm/page_frag/page_frag_test.c
> @@ -0,0 +1,170 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +/*
> + * Test module for page_frag cache
> + *
> + * Copyright: linyunsheng@huawei.com
> + */
> +
> +#include <linux/mm.h>
> +#include <linux/module.h>
> +#include <linux/cpumask.h>
> +#include <linux/completion.h>
> +#include <linux/ptr_ring.h>
> +#include <linux/kthread.h>
> +
> +static struct ptr_ring ptr_ring;
> +static int nr_objs = 512;
> +static atomic_t nthreads;
> +static struct completion wait;
> +static struct page_frag_cache test_frag;
> +
> +static int nr_test = 5120000;
> +module_param(nr_test, int, 0);
> +MODULE_PARM_DESC(nr_test, "number of iterations to test");
> +
> +static bool test_align;
> +module_param(test_align, bool, 0);
> +MODULE_PARM_DESC(test_align, "use align API for testing");
> +
> +static int test_alloc_len = 2048;
> +module_param(test_alloc_len, int, 0);
> +MODULE_PARM_DESC(test_alloc_len, "alloc len for testing");
> +
> +static int test_push_cpu;
> +module_param(test_push_cpu, int, 0);
> +MODULE_PARM_DESC(test_push_cpu, "test cpu for pushing fragment");
> +
> +static int test_pop_cpu;
> +module_param(test_pop_cpu, int, 0);
> +MODULE_PARM_DESC(test_pop_cpu, "test cpu for popping fragment");
> +
> +static int page_frag_pop_thread(void *arg)
> +{
> +	struct ptr_ring *ring = arg;
> +	int nr = nr_test;
> +
> +	pr_info("page_frag pop test thread begins on cpu %d\n",
> +		smp_processor_id());
> +
> +	while (nr > 0) {
> +		void *obj = __ptr_ring_consume(ring);
> +
> +		if (obj) {
> +			nr--;
> +			page_frag_free(obj);
> +		} else {
> +			cond_resched();
> +		}
> +	}
> +
> +	if (atomic_dec_and_test(&nthreads))
> +		complete(&wait);
> +
> +	pr_info("page_frag pop test thread exits on cpu %d\n",
> +		smp_processor_id());
> +
> +	return 0;
> +}
> +
> +static int page_frag_push_thread(void *arg)
> +{
> +	struct ptr_ring *ring = arg;
> +	int nr = nr_test;
> +
> +	pr_info("page_frag push test thread begins on cpu %d\n",
> +		smp_processor_id());
> +
> +	while (nr > 0) {
> +		void *va;
> +		int ret;
> +
> +		if (test_align) {
> +			va = page_frag_alloc_align(&test_frag, test_alloc_len,
> +						   GFP_KERNEL, SMP_CACHE_BYTES);
> +
> +			WARN_ONCE((unsigned long)va & (SMP_CACHE_BYTES - 1),
> +				  "unaligned va returned\n");
> +		} else {
> +			va = page_frag_alloc(&test_frag, test_alloc_len, GFP_KERNEL);
> +		}
> +
> +		if (!va)
> +			continue;
> +
> +		ret = __ptr_ring_produce(ring, va);
> +		if (ret) {
> +			page_frag_free(va);
> +			cond_resched();
> +		} else {
> +			nr--;
> +		}
> +	}
> +
> +	pr_info("page_frag push test thread exits on cpu %d\n",
> +		smp_processor_id());
> +
> +	if (atomic_dec_and_test(&nthreads))
> +		complete(&wait);
> +
> +	return 0;
> +}
> +
> +static int __init page_frag_test_init(void)
> +{
> +	struct task_struct *tsk_push, *tsk_pop;
> +	ktime_t start;
> +	u64 duration;
> +	int ret;
> +
> +	test_frag.va = NULL;
> +	atomic_set(&nthreads, 2);
> +	init_completion(&wait);
> +
> +	if (test_alloc_len > PAGE_SIZE || test_alloc_len <= 0 ||
> +	    !cpu_active(test_push_cpu) || !cpu_active(test_pop_cpu))
> +		return -EINVAL;
> +
> +	ret = ptr_ring_init(&ptr_ring, nr_objs, GFP_KERNEL);
> +	if (ret)
> +		return ret;
> +
> +	tsk_push = kthread_create_on_cpu(page_frag_push_thread, &ptr_ring,
> +					 test_push_cpu, "page_frag_push");
> +	if (IS_ERR(tsk_push))
> +		return PTR_ERR(tsk_push);
> +
> +	tsk_pop = kthread_create_on_cpu(page_frag_pop_thread, &ptr_ring,
> +					test_pop_cpu, "page_frag_pop");
> +	if (IS_ERR(tsk_pop)) {
> +		kthread_stop(tsk_push);
> +		return PTR_ERR(tsk_pop);
> +	}
> +
> +	start = ktime_get();
> +	wake_up_process(tsk_push);
> +	wake_up_process(tsk_pop);
> +
> +	pr_info("waiting for test to complete\n");
> +	wait_for_completion(&wait);
> +
> +	duration = (u64)ktime_us_delta(ktime_get(), start);
> +	pr_info("%d of iterations for %s testing took: %lluus\n", nr_test,
> +		test_align ? "aligned" : "non-aligned", duration);
> +
> +	ptr_ring_cleanup(&ptr_ring, NULL);
> +	page_frag_cache_drain(&test_frag);
> +
> +	return -EAGAIN;
> +}
> +
> +static void __exit page_frag_test_exit(void)
> +{
> +}
> +
> +module_init(page_frag_test_init);
> +module_exit(page_frag_test_exit);
> +
> +MODULE_LICENSE("GPL");
> +MODULE_AUTHOR("Yunsheng Lin <linyunsheng@huawei.com>");
> +MODULE_DESCRIPTION("Test module for page_frag");
> diff --git a/tools/testing/selftests/mm/run_vmtests.sh b/tools/testing/selftests/mm/run_vmtests.sh
> index 03ac4f2e1cce..3636d984b786 100755
> --- a/tools/testing/selftests/mm/run_vmtests.sh
> +++ b/tools/testing/selftests/mm/run_vmtests.sh
> @@ -75,6 +75,8 @@ separated by spaces:
>  	read-only VMAs
>  - mdwe
>  	test prctl(PR_SET_MDWE, ...)
> +- page_frag
> +	test handling of page fragment allocation and freeing
>  
>  example: ./run_vmtests.sh -t "hmm mmap ksm"
>  EOF
> @@ -231,7 +233,8 @@ run_test() {
>  		("$@" 2>&1) | tap_prefix
>  		local ret=${PIPESTATUS[0]}
>  		count_total=$(( count_total + 1 ))
> -		if [ $ret -eq 0 ]; then
> +		# page_frag_test.ko returns 11(EAGAIN) when insmod'ing to avoid rmmod
> +		if [ $ret -eq 0 ] | [ $ret -eq 11 -a ${CATEGORY} == "page_frag" ]; then
>  			count_pass=$(( count_pass + 1 ))
>  			echo "[PASS]" | tap_prefix
>  			echo "ok ${count_total} ${test}" | tap_output
> @@ -453,6 +456,10 @@ CATEGORY="mkdirty" run_test ./mkdirty
>  
>  CATEGORY="mdwe" run_test ./mdwe_test
>  
> +CATEGORY="page_frag" run_test insmod ./page_frag/page_frag_test.ko
> +
> +CATEGORY="page_frag" run_test insmod ./page_frag/page_frag_test.ko test_alloc_len=12 test_align=1
> +
You are loading the test module. How will we verify if the test passed
or failed? There must be a way to mark the test passed or failed after
running it. You can definitely parse the dmesg to get results. But it
would be complex to do it. KUnit is way to go as all such tools are
already present there.

>  echo "SUMMARY: PASS=${count_pass} SKIP=${count_skip} FAIL=${count_fail}" | tap_prefix
>  echo "1..${count_total}" | tap_output
>  

-- 
BR,
Muhammad Usama Anjum

Re: [PATCH net-next v13 01/14] mm: page_frag: add a test module for page_frag

[Yunsheng Lin]

On 2024/8/9 19:08, Muhammad Usama Anjum wrote:
> On 8/8/24 5:37 PM, Yunsheng Lin wrote:
>> The testing is done by ensuring that the fragment allocated
>> from a frag_frag_cache instance is pushed into a ptr_ring
>> instance in a kthread binded to a specified cpu, and a kthread
>> binded to a specified cpu will pop the fragment from the
>> ptr_ring and free the fragment.
>>
>> CC: Alexander Duyck <alexander.duyck@gmail.com>
>> Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
>> ---
>>  tools/testing/selftests/mm/Makefile           |   2 +
>>  tools/testing/selftests/mm/page_frag/Makefile |  18 ++
>>  .../selftests/mm/page_frag/page_frag_test.c   | 170 ++++++++++++++++++
> Why are you adding a test module in kselftests? Have you considered
> adding Kunit instead? Kunit is more suited to test kernel's internal
> APIs which aren't exposed to userspace.

The main intent is to do performance impact of changing related to
page_frag, which is very much performance sensitive, so I am guessing
Kunit is not a right choice here if I am understanding it correctly.

> 
>>  tools/testing/selftests/mm/run_vmtests.sh     |   9 +-
>>  4 files changed, 198 insertions(+), 1 deletion(-)
>>  create mode 100644 tools/testing/selftests/mm/page_frag/Makefile
>>  create mode 100644 tools/testing/selftests/mm/page_frag/page_frag_test.c
>>
>> diff --git a/tools/testing/selftests/mm/Makefile b/tools/testing/selftests/mm/Makefile
>> index 901e0d07765b..e91ed29378fc 100644
>> --- a/tools/testing/selftests/mm/Makefile
>> +++ b/tools/testing/selftests/mm/Makefile
>> @@ -36,6 +36,8 @@ MAKEFLAGS += --no-builtin-rules
>>  CFLAGS = -Wall -I $(top_srcdir) $(EXTRA_CFLAGS) $(KHDR_INCLUDES) $(TOOLS_INCLUDES)
>>  LDLIBS = -lrt -lpthread -lm
>>  
>> +TEST_GEN_MODS_DIR := page_frag
>> +
>>  TEST_GEN_FILES = cow
>>  TEST_GEN_FILES += compaction_test
>>  TEST_GEN_FILES += gup_longterm
>> diff --git a/tools/testing/selftests/mm/page_frag/Makefile b/tools/testing/selftests/mm/page_frag/Makefile
>> new file mode 100644
>> index 000000000000..58dda74d50a3
>> --- /dev/null
>> +++ b/tools/testing/selftests/mm/page_frag/Makefile
>> @@ -0,0 +1,18 @@
>> +PAGE_FRAG_TEST_DIR := $(realpath $(dir $(abspath $(lastword $(MAKEFILE_LIST)))))
>> +KDIR ?= $(abspath $(PAGE_FRAG_TEST_DIR)/../../../../..)
>> +
>> +ifeq ($(V),1)
>> +Q =
>> +else
>> +Q = @
>> +endif
>> +
>> +MODULES = page_frag_test.ko
>> +
>> +obj-m += page_frag_test.o
>> +
>> +all:
>> +	+$(Q)make -C $(KDIR) M=$(PAGE_FRAG_TEST_DIR) modules
>> +
>> +clean:
>> +	+$(Q)make -C $(KDIR) M=$(PAGE_FRAG_TEST_DIR) clean
>> diff --git a/tools/testing/selftests/mm/page_frag/page_frag_test.c b/tools/testing/selftests/mm/page_frag/page_frag_test.c
>> new file mode 100644
>> index 000000000000..0e803db1ad79
>> --- /dev/null
>> +++ b/tools/testing/selftests/mm/page_frag/page_frag_test.c
>> @@ -0,0 +1,170 @@
>> +// SPDX-License-Identifier: GPL-2.0
>> +
>> +/*
>> + * Test module for page_frag cache
>> + *
>> + * Copyright: linyunsheng@huawei.com
>> + */
>> +
>> +#include <linux/mm.h>
>> +#include <linux/module.h>
>> +#include <linux/cpumask.h>
>> +#include <linux/completion.h>
>> +#include <linux/ptr_ring.h>
>> +#include <linux/kthread.h>
>> +
>> +static struct ptr_ring ptr_ring;
>> +static int nr_objs = 512;
>> +static atomic_t nthreads;
>> +static struct completion wait;
>> +static struct page_frag_cache test_frag;
>> +
>> +static int nr_test = 5120000;
>> +module_param(nr_test, int, 0);
>> +MODULE_PARM_DESC(nr_test, "number of iterations to test");
>> +
>> +static bool test_align;
>> +module_param(test_align, bool, 0);
>> +MODULE_PARM_DESC(test_align, "use align API for testing");
>> +
>> +static int test_alloc_len = 2048;
>> +module_param(test_alloc_len, int, 0);
>> +MODULE_PARM_DESC(test_alloc_len, "alloc len for testing");
>> +
>> +static int test_push_cpu;
>> +module_param(test_push_cpu, int, 0);
>> +MODULE_PARM_DESC(test_push_cpu, "test cpu for pushing fragment");
>> +
>> +static int test_pop_cpu;
>> +module_param(test_pop_cpu, int, 0);
>> +MODULE_PARM_DESC(test_pop_cpu, "test cpu for popping fragment");
>> +
>> +static int page_frag_pop_thread(void *arg)
>> +{
>> +	struct ptr_ring *ring = arg;
>> +	int nr = nr_test;
>> +
>> +	pr_info("page_frag pop test thread begins on cpu %d\n",
>> +		smp_processor_id());
>> +
>> +	while (nr > 0) {
>> +		void *obj = __ptr_ring_consume(ring);
>> +
>> +		if (obj) {
>> +			nr--;
>> +			page_frag_free(obj);
>> +		} else {
>> +			cond_resched();
>> +		}
>> +	}
>> +
>> +	if (atomic_dec_and_test(&nthreads))
>> +		complete(&wait);
>> +
>> +	pr_info("page_frag pop test thread exits on cpu %d\n",
>> +		smp_processor_id());
>> +
>> +	return 0;
>> +}
>> +
>> +static int page_frag_push_thread(void *arg)
>> +{
>> +	struct ptr_ring *ring = arg;
>> +	int nr = nr_test;
>> +
>> +	pr_info("page_frag push test thread begins on cpu %d\n",
>> +		smp_processor_id());
>> +
>> +	while (nr > 0) {
>> +		void *va;
>> +		int ret;
>> +
>> +		if (test_align) {
>> +			va = page_frag_alloc_align(&test_frag, test_alloc_len,
>> +						   GFP_KERNEL, SMP_CACHE_BYTES);
>> +
>> +			WARN_ONCE((unsigned long)va & (SMP_CACHE_BYTES - 1),
>> +				  "unaligned va returned\n");
>> +		} else {
>> +			va = page_frag_alloc(&test_frag, test_alloc_len, GFP_KERNEL);
>> +		}
>> +
>> +		if (!va)
>> +			continue;
>> +
>> +		ret = __ptr_ring_produce(ring, va);
>> +		if (ret) {
>> +			page_frag_free(va);
>> +			cond_resched();
>> +		} else {
>> +			nr--;
>> +		}
>> +	}
>> +
>> +	pr_info("page_frag push test thread exits on cpu %d\n",
>> +		smp_processor_id());
>> +
>> +	if (atomic_dec_and_test(&nthreads))
>> +		complete(&wait);
>> +
>> +	return 0;
>> +}
>> +
>> +static int __init page_frag_test_init(void)
>> +{
>> +	struct task_struct *tsk_push, *tsk_pop;
>> +	ktime_t start;
>> +	u64 duration;
>> +	int ret;
>> +
>> +	test_frag.va = NULL;
>> +	atomic_set(&nthreads, 2);
>> +	init_completion(&wait);
>> +
>> +	if (test_alloc_len > PAGE_SIZE || test_alloc_len <= 0 ||
>> +	    !cpu_active(test_push_cpu) || !cpu_active(test_pop_cpu))
>> +		return -EINVAL;
>> +
>> +	ret = ptr_ring_init(&ptr_ring, nr_objs, GFP_KERNEL);
>> +	if (ret)
>> +		return ret;
>> +
>> +	tsk_push = kthread_create_on_cpu(page_frag_push_thread, &ptr_ring,
>> +					 test_push_cpu, "page_frag_push");
>> +	if (IS_ERR(tsk_push))
>> +		return PTR_ERR(tsk_push);
>> +
>> +	tsk_pop = kthread_create_on_cpu(page_frag_pop_thread, &ptr_ring,
>> +					test_pop_cpu, "page_frag_pop");
>> +	if (IS_ERR(tsk_pop)) {
>> +		kthread_stop(tsk_push);
>> +		return PTR_ERR(tsk_pop);
>> +	}
>> +
>> +	start = ktime_get();
>> +	wake_up_process(tsk_push);
>> +	wake_up_process(tsk_pop);
>> +
>> +	pr_info("waiting for test to complete\n");
>> +	wait_for_completion(&wait);
>> +
>> +	duration = (u64)ktime_us_delta(ktime_get(), start);
>> +	pr_info("%d of iterations for %s testing took: %lluus\n", nr_test,
>> +		test_align ? "aligned" : "non-aligned", duration);
>> +
>> +	ptr_ring_cleanup(&ptr_ring, NULL);
>> +	page_frag_cache_drain(&test_frag);
>> +
>> +	return -EAGAIN;
>> +}
>> +
>> +static void __exit page_frag_test_exit(void)
>> +{
>> +}
>> +
>> +module_init(page_frag_test_init);
>> +module_exit(page_frag_test_exit);
>> +
>> +MODULE_LICENSE("GPL");
>> +MODULE_AUTHOR("Yunsheng Lin <linyunsheng@huawei.com>");
>> +MODULE_DESCRIPTION("Test module for page_frag");
>> diff --git a/tools/testing/selftests/mm/run_vmtests.sh b/tools/testing/selftests/mm/run_vmtests.sh
>> index 03ac4f2e1cce..3636d984b786 100755
>> --- a/tools/testing/selftests/mm/run_vmtests.sh
>> +++ b/tools/testing/selftests/mm/run_vmtests.sh
>> @@ -75,6 +75,8 @@ separated by spaces:
>>  	read-only VMAs
>>  - mdwe
>>  	test prctl(PR_SET_MDWE, ...)
>> +- page_frag
>> +	test handling of page fragment allocation and freeing
>>  
>>  example: ./run_vmtests.sh -t "hmm mmap ksm"
>>  EOF
>> @@ -231,7 +233,8 @@ run_test() {
>>  		("$@" 2>&1) | tap_prefix
>>  		local ret=${PIPESTATUS[0]}
>>  		count_total=$(( count_total + 1 ))
>> -		if [ $ret -eq 0 ]; then
>> +		# page_frag_test.ko returns 11(EAGAIN) when insmod'ing to avoid rmmod
>> +		if [ $ret -eq 0 ] | [ $ret -eq 11 -a ${CATEGORY} == "page_frag" ]; then
>>  			count_pass=$(( count_pass + 1 ))
>>  			echo "[PASS]" | tap_prefix
>>  			echo "ok ${count_total} ${test}" | tap_output
>> @@ -453,6 +456,10 @@ CATEGORY="mkdirty" run_test ./mkdirty
>>  
>>  CATEGORY="mdwe" run_test ./mdwe_test
>>  
>> +CATEGORY="page_frag" run_test insmod ./page_frag/page_frag_test.ko
>> +
>> +CATEGORY="page_frag" run_test insmod ./page_frag/page_frag_test.ko test_alloc_len=12 test_align=1
>> +
> You are loading the test module. How will we verify if the test passed
> or failed? There must be a way to mark the test passed or failed after

I am not sure that matter that much for page_frag_test module as it
already return -EAGAIN for normal case as mentioned in:

https://patchwork.kernel.org/project/netdevbpf/patch/20240731124505.2903877-2-linyunsheng@huawei.com/#25960885

> running it. You can definitely parse the dmesg to get results. But it
> would be complex to do it. KUnit is way to go as all such tools are
> already present there.

Re: [PATCH net-next v13 02/14] mm: move the page fragment allocator from page_alloc into its own file

[Alexander H Duyck]

On Thu, 2024-08-08 at 20:37 +0800, Yunsheng Lin wrote:
> Inspired by [1], move the page fragment allocator from page_alloc
> into its own c file and header file, as we are about to make more
> change for it to replace another page_frag implementation in
> sock.c
> 
> As this patchset is going to replace 'struct page_frag' with
> 'struct page_frag_cache' in sched.h, including page_frag_cache.h
> in sched.h has a compiler error caused by interdependence between
> mm_types.h and mm.h for asm-offsets.c, see [2]. So avoid the compiler
> error by moving 'struct page_frag_cache' to mm_types_task.h as
> suggested by Alexander, see [3].
> 
> 1. https://lore.kernel.org/all/20230411160902.4134381-3-dhowells@redhat.com/
> 2. https://lore.kernel.org/all/15623dac-9358-4597-b3ee-3694a5956920@gmail.com/
> 3. https://lore.kernel.org/all/CAKgT0UdH1yD=LSCXFJ=YM_aiA4OomD-2wXykO42bizaWMt_HOA@mail.gmail.com/
> CC: David Howells <dhowells@redhat.com>
> CC: Alexander Duyck <alexander.duyck@gmail.com>
> Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
> ---
>  include/linux/gfp.h                           |  22 ---
>  include/linux/mm_types.h                      |  18 ---
>  include/linux/mm_types_task.h                 |  18 +++
>  include/linux/page_frag_cache.h               |  31 ++++
>  include/linux/skbuff.h                        |   1 +
>  mm/Makefile                                   |   1 +
>  mm/page_alloc.c                               | 136 ----------------
>  mm/page_frag_cache.c                          | 145 ++++++++++++++++++
>  .../selftests/mm/page_frag/page_frag_test.c   |   2 +-
>  9 files changed, 197 insertions(+), 177 deletions(-)
>  create mode 100644 include/linux/page_frag_cache.h
>  create mode 100644 mm/page_frag_cache.c
> 
> 

...

> diff --git a/include/linux/page_frag_cache.h b/include/linux/page_frag_cache.h
> new file mode 100644
> index 000000000000..a758cb65a9b3
> --- /dev/null
> +++ b/include/linux/page_frag_cache.h
> @@ -0,0 +1,31 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +
> +#ifndef _LINUX_PAGE_FRAG_CACHE_H
> +#define _LINUX_PAGE_FRAG_CACHE_H
> +
> +#include <linux/log2.h>
> +#include <linux/types.h>
> +#include <linux/mm_types_task.h>
> +

Minor nit. These should usually be in alphabetical order. So
mm_types_task.h should be between log2.h and types.h.

Re: [PATCH net-next v13 02/14] mm: move the page fragment allocator from page_alloc into its own file

[Andrew Morton]

On Thu, 8 Aug 2024 20:37:02 +0800 Yunsheng Lin <linyunsheng@huawei.com> wrote:

> Inspired by [1], move the page fragment allocator from page_alloc
> into its own c file and header file, as we are about to make more
> change for it to replace another page_frag implementation in
> sock.c

Acked-by: Andrew Morton <akpm@linux-foundation.org>

This presently has no conflicts with mm.git.

Re: [PATCH net-next v13 04/14] mm: page_frag: add '_va' suffix to page_frag API

[Alexander H Duyck]

On Thu, 2024-08-08 at 20:37 +0800, Yunsheng Lin wrote:
> Currently the page_frag API is returning 'virtual address'
> or 'va' when allocing and expecting 'virtual address' or
> 'va' as input when freeing.
> 
> As we are about to support new use cases that the caller
> need to deal with 'struct page' or need to deal with both
> 'va' and 'struct page'. In order to differentiate the API
> handling between 'va' and 'struct page', add '_va' suffix
> to the corresponding API mirroring the page_pool_alloc_va()
> API of the page_pool. So that callers expecting to deal with
> va, page or both va and page may call page_frag_alloc_va*,
> page_frag_alloc_pg*, or page_frag_alloc* API accordingly.
> 
> CC: Alexander Duyck <alexander.duyck@gmail.com>
> Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
> Reviewed-by: Subbaraya Sundeep <sbhatta@marvell.com>
> Acked-by: Chuck Lever <chuck.lever@oracle.com>
> Acked-by: Sagi Grimberg <sagi@grimberg.me>
> ---
>  drivers/net/ethernet/google/gve/gve_rx.c      |  4 ++--
>  drivers/net/ethernet/intel/ice/ice_txrx.c     |  2 +-
>  drivers/net/ethernet/intel/ice/ice_txrx.h     |  2 +-
>  drivers/net/ethernet/intel/ice/ice_txrx_lib.c |  2 +-
>  .../net/ethernet/intel/ixgbevf/ixgbevf_main.c |  4 ++--
>  .../marvell/octeontx2/nic/otx2_common.c       |  2 +-
>  drivers/net/ethernet/mediatek/mtk_wed_wo.c    |  4 ++--
>  drivers/nvme/host/tcp.c                       |  8 +++----
>  drivers/nvme/target/tcp.c                     | 22 +++++++++----------
>  drivers/vhost/net.c                           |  6 ++---
>  include/linux/page_frag_cache.h               | 21 +++++++++---------
>  include/linux/skbuff.h                        |  2 +-
>  kernel/bpf/cpumap.c                           |  2 +-
>  mm/page_frag_cache.c                          | 12 +++++-----
>  net/core/skbuff.c                             | 16 +++++++-------
>  net/core/xdp.c                                |  2 +-
>  net/rxrpc/txbuf.c                             | 15 +++++++------
>  net/sunrpc/svcsock.c                          |  6 ++---
>  .../selftests/mm/page_frag/page_frag_test.c   | 13 ++++++-----
>  19 files changed, 75 insertions(+), 70 deletions(-)
> 

I still say no to this patch. It is an unnecessary name change and adds
no value. If you insist on this patch I will reject the set every time.

The fact is it is polluting the git history and just makes things
harder to maintain without adding any value as you aren't changing what
the function does and there is no need for this. In addition it just
makes it that much harder to backport fixes in the future as people
will have to work around the rename.

Re: [PATCH net-next v13 04/14] mm: page_frag: add '_va' suffix to page_frag API

[Yunsheng Lin]

On 2024/8/14 23:49, Alexander H Duyck wrote:
> On Thu, 2024-08-08 at 20:37 +0800, Yunsheng Lin wrote:
>> Currently the page_frag API is returning 'virtual address'
>> or 'va' when allocing and expecting 'virtual address' or
>> 'va' as input when freeing.
>>
>> As we are about to support new use cases that the caller
>> need to deal with 'struct page' or need to deal with both
>> 'va' and 'struct page'. In order to differentiate the API
>> handling between 'va' and 'struct page', add '_va' suffix
>> to the corresponding API mirroring the page_pool_alloc_va()
>> API of the page_pool. So that callers expecting to deal with
>> va, page or both va and page may call page_frag_alloc_va*,
>> page_frag_alloc_pg*, or page_frag_alloc* API accordingly.
>>
>> CC: Alexander Duyck <alexander.duyck@gmail.com>
>> Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
>> Reviewed-by: Subbaraya Sundeep <sbhatta@marvell.com>
>> Acked-by: Chuck Lever <chuck.lever@oracle.com>
>> Acked-by: Sagi Grimberg <sagi@grimberg.me>
>> ---
>>  drivers/net/ethernet/google/gve/gve_rx.c      |  4 ++--
>>  drivers/net/ethernet/intel/ice/ice_txrx.c     |  2 +-
>>  drivers/net/ethernet/intel/ice/ice_txrx.h     |  2 +-
>>  drivers/net/ethernet/intel/ice/ice_txrx_lib.c |  2 +-
>>  .../net/ethernet/intel/ixgbevf/ixgbevf_main.c |  4 ++--
>>  .../marvell/octeontx2/nic/otx2_common.c       |  2 +-
>>  drivers/net/ethernet/mediatek/mtk_wed_wo.c    |  4 ++--
>>  drivers/nvme/host/tcp.c                       |  8 +++----
>>  drivers/nvme/target/tcp.c                     | 22 +++++++++----------
>>  drivers/vhost/net.c                           |  6 ++---
>>  include/linux/page_frag_cache.h               | 21 +++++++++---------
>>  include/linux/skbuff.h                        |  2 +-
>>  kernel/bpf/cpumap.c                           |  2 +-
>>  mm/page_frag_cache.c                          | 12 +++++-----
>>  net/core/skbuff.c                             | 16 +++++++-------
>>  net/core/xdp.c                                |  2 +-
>>  net/rxrpc/txbuf.c                             | 15 +++++++------
>>  net/sunrpc/svcsock.c                          |  6 ++---
>>  .../selftests/mm/page_frag/page_frag_test.c   | 13 ++++++-----
>>  19 files changed, 75 insertions(+), 70 deletions(-)
>>
> 
> I still say no to this patch. It is an unnecessary name change and adds
> no value. If you insist on this patch I will reject the set every time.
> 
> The fact is it is polluting the git history and just makes things
> harder to maintain without adding any value as you aren't changing what
> the function does and there is no need for this. In addition it just

I guess I have to disagree with the above 'no need for this' part for
now, as mentioned in [1]:

"There are three types of API as proposed in this patchset instead of
two types of API:
1. page_frag_alloc_va() returns [va].
2. page_frag_alloc_pg() returns [page, offset].
3. page_frag_alloc() returns [va] & [page, offset].

You seemed to miss that we need a third naming for the type 3 API.
Do you see type 3 API as a valid API? if yes, what naming are you
suggesting for it? if no, why it is not a valid API?"


1. https://lore.kernel.org/all/ca6be29e-ab53-4673-9624-90d41616a154@huawei.com/

> makes it that much harder to backport fixes in the future as people
> will have to work around the rename.
> 

Re: [PATCH net-next v13 04/14] mm: page_frag: add '_va' suffix to page_frag API

[Alexander Duyck]

On Wed, Aug 14, 2024 at 8:00 PM Yunsheng Lin <linyunsheng@huawei.com> wrote:
>
> On 2024/8/14 23:49, Alexander H Duyck wrote:
> > On Thu, 2024-08-08 at 20:37 +0800, Yunsheng Lin wrote:
> >> Currently the page_frag API is returning 'virtual address'
> >> or 'va' when allocing and expecting 'virtual address' or
> >> 'va' as input when freeing.
> >>
> >> As we are about to support new use cases that the caller
> >> need to deal with 'struct page' or need to deal with both
> >> 'va' and 'struct page'. In order to differentiate the API
> >> handling between 'va' and 'struct page', add '_va' suffix
> >> to the corresponding API mirroring the page_pool_alloc_va()
> >> API of the page_pool. So that callers expecting to deal with
> >> va, page or both va and page may call page_frag_alloc_va*,
> >> page_frag_alloc_pg*, or page_frag_alloc* API accordingly.
> >>
> >> CC: Alexander Duyck <alexander.duyck@gmail.com>
> >> Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
> >> Reviewed-by: Subbaraya Sundeep <sbhatta@marvell.com>
> >> Acked-by: Chuck Lever <chuck.lever@oracle.com>
> >> Acked-by: Sagi Grimberg <sagi@grimberg.me>
> >> ---
> >>  drivers/net/ethernet/google/gve/gve_rx.c      |  4 ++--
> >>  drivers/net/ethernet/intel/ice/ice_txrx.c     |  2 +-
> >>  drivers/net/ethernet/intel/ice/ice_txrx.h     |  2 +-
> >>  drivers/net/ethernet/intel/ice/ice_txrx_lib.c |  2 +-
> >>  .../net/ethernet/intel/ixgbevf/ixgbevf_main.c |  4 ++--
> >>  .../marvell/octeontx2/nic/otx2_common.c       |  2 +-
> >>  drivers/net/ethernet/mediatek/mtk_wed_wo.c    |  4 ++--
> >>  drivers/nvme/host/tcp.c                       |  8 +++----
> >>  drivers/nvme/target/tcp.c                     | 22 +++++++++----------
> >>  drivers/vhost/net.c                           |  6 ++---
> >>  include/linux/page_frag_cache.h               | 21 +++++++++---------
> >>  include/linux/skbuff.h                        |  2 +-
> >>  kernel/bpf/cpumap.c                           |  2 +-
> >>  mm/page_frag_cache.c                          | 12 +++++-----
> >>  net/core/skbuff.c                             | 16 +++++++-------
> >>  net/core/xdp.c                                |  2 +-
> >>  net/rxrpc/txbuf.c                             | 15 +++++++------
> >>  net/sunrpc/svcsock.c                          |  6 ++---
> >>  .../selftests/mm/page_frag/page_frag_test.c   | 13 ++++++-----
> >>  19 files changed, 75 insertions(+), 70 deletions(-)
> >>
> >
> > I still say no to this patch. It is an unnecessary name change and adds
> > no value. If you insist on this patch I will reject the set every time.
> >
> > The fact is it is polluting the git history and just makes things
> > harder to maintain without adding any value as you aren't changing what
> > the function does and there is no need for this. In addition it just
>
> I guess I have to disagree with the above 'no need for this' part for
> now, as mentioned in [1]:
>
> "There are three types of API as proposed in this patchset instead of
> two types of API:
> 1. page_frag_alloc_va() returns [va].
> 2. page_frag_alloc_pg() returns [page, offset].
> 3. page_frag_alloc() returns [va] & [page, offset].
>
> You seemed to miss that we need a third naming for the type 3 API.
> Do you see type 3 API as a valid API? if yes, what naming are you
> suggesting for it? if no, why it is not a valid API?"

I didn't. I just don't see the point in pushing out the existing API
to support that. In reality 2 and 3 are redundant. You probably only
need 3. Like I mentioned earlier you can essentially just pass a
page_frag via pointer to the function. With that you could also look
at just returning a virtual address as well if you insist on having
something that returns all of the above. No point in having 2 and 3 be
seperate functions.

I am going to nack this patch set if you insist on this pointless
renaming. The fact is it is just adding noise that adds no value.

Re: [PATCH net-next v13 04/14] mm: page_frag: add '_va' suffix to page_frag API

[Yunsheng Lin]

On 2024/8/15 23:00, Alexander Duyck wrote:
> On Wed, Aug 14, 2024 at 8:00 PM Yunsheng Lin <linyunsheng@huawei.com> wrote:
>>
>> On 2024/8/14 23:49, Alexander H Duyck wrote:
>>> On Thu, 2024-08-08 at 20:37 +0800, Yunsheng Lin wrote:
>>>> Currently the page_frag API is returning 'virtual address'
>>>> or 'va' when allocing and expecting 'virtual address' or
>>>> 'va' as input when freeing.
>>>>
>>>> As we are about to support new use cases that the caller
>>>> need to deal with 'struct page' or need to deal with both
>>>> 'va' and 'struct page'. In order to differentiate the API
>>>> handling between 'va' and 'struct page', add '_va' suffix
>>>> to the corresponding API mirroring the page_pool_alloc_va()
>>>> API of the page_pool. So that callers expecting to deal with
>>>> va, page or both va and page may call page_frag_alloc_va*,
>>>> page_frag_alloc_pg*, or page_frag_alloc* API accordingly.
>>>>
>>>> CC: Alexander Duyck <alexander.duyck@gmail.com>
>>>> Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
>>>> Reviewed-by: Subbaraya Sundeep <sbhatta@marvell.com>
>>>> Acked-by: Chuck Lever <chuck.lever@oracle.com>
>>>> Acked-by: Sagi Grimberg <sagi@grimberg.me>
>>>> ---
>>>>  drivers/net/ethernet/google/gve/gve_rx.c      |  4 ++--
>>>>  drivers/net/ethernet/intel/ice/ice_txrx.c     |  2 +-
>>>>  drivers/net/ethernet/intel/ice/ice_txrx.h     |  2 +-
>>>>  drivers/net/ethernet/intel/ice/ice_txrx_lib.c |  2 +-
>>>>  .../net/ethernet/intel/ixgbevf/ixgbevf_main.c |  4 ++--
>>>>  .../marvell/octeontx2/nic/otx2_common.c       |  2 +-
>>>>  drivers/net/ethernet/mediatek/mtk_wed_wo.c    |  4 ++--
>>>>  drivers/nvme/host/tcp.c                       |  8 +++----
>>>>  drivers/nvme/target/tcp.c                     | 22 +++++++++----------
>>>>  drivers/vhost/net.c                           |  6 ++---
>>>>  include/linux/page_frag_cache.h               | 21 +++++++++---------
>>>>  include/linux/skbuff.h                        |  2 +-
>>>>  kernel/bpf/cpumap.c                           |  2 +-
>>>>  mm/page_frag_cache.c                          | 12 +++++-----
>>>>  net/core/skbuff.c                             | 16 +++++++-------
>>>>  net/core/xdp.c                                |  2 +-
>>>>  net/rxrpc/txbuf.c                             | 15 +++++++------
>>>>  net/sunrpc/svcsock.c                          |  6 ++---
>>>>  .../selftests/mm/page_frag/page_frag_test.c   | 13 ++++++-----
>>>>  19 files changed, 75 insertions(+), 70 deletions(-)
>>>>
>>>
>>> I still say no to this patch. It is an unnecessary name change and adds
>>> no value. If you insist on this patch I will reject the set every time.
>>>
>>> The fact is it is polluting the git history and just makes things
>>> harder to maintain without adding any value as you aren't changing what
>>> the function does and there is no need for this. In addition it just
>>
>> I guess I have to disagree with the above 'no need for this' part for
>> now, as mentioned in [1]:
>>
>> "There are three types of API as proposed in this patchset instead of
>> two types of API:
>> 1. page_frag_alloc_va() returns [va].
>> 2. page_frag_alloc_pg() returns [page, offset].
>> 3. page_frag_alloc() returns [va] & [page, offset].
>>
>> You seemed to miss that we need a third naming for the type 3 API.
>> Do you see type 3 API as a valid API? if yes, what naming are you
>> suggesting for it? if no, why it is not a valid API?"
> 
> I didn't. I just don't see the point in pushing out the existing API
> to support that. In reality 2 and 3 are redundant. You probably only
> need 3. Like I mentioned earlier you can essentially just pass a

If the caller just expect [page, offset], do you expect the caller also
type 3 API, which return both [va] and [page, offset]?

I am not sure if I understand why you think 2 and 3 are redundant here?
If you think 2 and 3 are redundant here, aren't 1 and 3 also redundant
as the similar agrument?

> page_frag via pointer to the function. With that you could also look
> at just returning a virtual address as well if you insist on having
> something that returns all of the above. No point in having 2 and 3 be
> seperate functions.

Let's be more specific about what are your suggestion here: which way
is the prefer way to return the virtual address. It seems there are two
options:

1. Return the virtual address by function returning as below:
void *page_frag_alloc_bio(struct page_frag_cache *nc, struct bio_vec *bio);

2. Return the virtual address by double pointer as below:
int page_frag_alloc_bio(struct page_frag_cache *nc, struct bio_vec *bio,
		        void **va);

If the above options is what you have in mind, please be more specific
which one is the prefer option, and why it is the prefer option.
If the above options is not what you have in mind, please list out the
declaration of API in your mind.

> 
> I am going to nack this patch set if you insist on this pointless
> renaming. The fact is it is just adding noise that adds no value.

Re: [PATCH net-next v13 04/14] mm: page_frag: add '_va' suffix to page_frag API

[Alexander Duyck]

On Fri, Aug 16, 2024 at 4:55 AM Yunsheng Lin <linyunsheng@huawei.com> wrote:
>
> On 2024/8/15 23:00, Alexander Duyck wrote:
> > On Wed, Aug 14, 2024 at 8:00 PM Yunsheng Lin <linyunsheng@huawei.com> wrote:
> >>
> >> On 2024/8/14 23:49, Alexander H Duyck wrote:
> >>> On Thu, 2024-08-08 at 20:37 +0800, Yunsheng Lin wrote:
> >>>> Currently the page_frag API is returning 'virtual address'
> >>>> or 'va' when allocing and expecting 'virtual address' or
> >>>> 'va' as input when freeing.
> >>>>
> >>>> As we are about to support new use cases that the caller
> >>>> need to deal with 'struct page' or need to deal with both
> >>>> 'va' and 'struct page'. In order to differentiate the API
> >>>> handling between 'va' and 'struct page', add '_va' suffix
> >>>> to the corresponding API mirroring the page_pool_alloc_va()
> >>>> API of the page_pool. So that callers expecting to deal with
> >>>> va, page or both va and page may call page_frag_alloc_va*,
> >>>> page_frag_alloc_pg*, or page_frag_alloc* API accordingly.
> >>>>
> >>>> CC: Alexander Duyck <alexander.duyck@gmail.com>
> >>>> Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
> >>>> Reviewed-by: Subbaraya Sundeep <sbhatta@marvell.com>
> >>>> Acked-by: Chuck Lever <chuck.lever@oracle.com>
> >>>> Acked-by: Sagi Grimberg <sagi@grimberg.me>
> >>>> ---
> >>>>  drivers/net/ethernet/google/gve/gve_rx.c      |  4 ++--
> >>>>  drivers/net/ethernet/intel/ice/ice_txrx.c     |  2 +-
> >>>>  drivers/net/ethernet/intel/ice/ice_txrx.h     |  2 +-
> >>>>  drivers/net/ethernet/intel/ice/ice_txrx_lib.c |  2 +-
> >>>>  .../net/ethernet/intel/ixgbevf/ixgbevf_main.c |  4 ++--
> >>>>  .../marvell/octeontx2/nic/otx2_common.c       |  2 +-
> >>>>  drivers/net/ethernet/mediatek/mtk_wed_wo.c    |  4 ++--
> >>>>  drivers/nvme/host/tcp.c                       |  8 +++----
> >>>>  drivers/nvme/target/tcp.c                     | 22 +++++++++----------
> >>>>  drivers/vhost/net.c                           |  6 ++---
> >>>>  include/linux/page_frag_cache.h               | 21 +++++++++---------
> >>>>  include/linux/skbuff.h                        |  2 +-
> >>>>  kernel/bpf/cpumap.c                           |  2 +-
> >>>>  mm/page_frag_cache.c                          | 12 +++++-----
> >>>>  net/core/skbuff.c                             | 16 +++++++-------
> >>>>  net/core/xdp.c                                |  2 +-
> >>>>  net/rxrpc/txbuf.c                             | 15 +++++++------
> >>>>  net/sunrpc/svcsock.c                          |  6 ++---
> >>>>  .../selftests/mm/page_frag/page_frag_test.c   | 13 ++++++-----
> >>>>  19 files changed, 75 insertions(+), 70 deletions(-)
> >>>>
> >>>
> >>> I still say no to this patch. It is an unnecessary name change and adds
> >>> no value. If you insist on this patch I will reject the set every time.
> >>>
> >>> The fact is it is polluting the git history and just makes things
> >>> harder to maintain without adding any value as you aren't changing what
> >>> the function does and there is no need for this. In addition it just
> >>
> >> I guess I have to disagree with the above 'no need for this' part for
> >> now, as mentioned in [1]:
> >>
> >> "There are three types of API as proposed in this patchset instead of
> >> two types of API:
> >> 1. page_frag_alloc_va() returns [va].
> >> 2. page_frag_alloc_pg() returns [page, offset].
> >> 3. page_frag_alloc() returns [va] & [page, offset].
> >>
> >> You seemed to miss that we need a third naming for the type 3 API.
> >> Do you see type 3 API as a valid API? if yes, what naming are you
> >> suggesting for it? if no, why it is not a valid API?"
> >
> > I didn't. I just don't see the point in pushing out the existing API
> > to support that. In reality 2 and 3 are redundant. You probably only
> > need 3. Like I mentioned earlier you can essentially just pass a
>
> If the caller just expect [page, offset], do you expect the caller also
> type 3 API, which return both [va] and [page, offset]?
>
> I am not sure if I understand why you think 2 and 3 are redundant here?
> If you think 2 and 3 are redundant here, aren't 1 and 3 also redundant
> as the similar agrument?

The big difference is the need to return page and offset. Basically to
support returning page and offset you need to pass at least one value
as a pointer so you can store the return there.

The reason why 3 is just a redundant form of 2 is that you will
normally just be converting from a va to a page and offset so the va
should already be easily accessible.

> > page_frag via pointer to the function. With that you could also look
> > at just returning a virtual address as well if you insist on having
> > something that returns all of the above. No point in having 2 and 3 be
> > seperate functions.
>
> Let's be more specific about what are your suggestion here: which way
> is the prefer way to return the virtual address. It seems there are two
> options:
>
> 1. Return the virtual address by function returning as below:
> void *page_frag_alloc_bio(struct page_frag_cache *nc, struct bio_vec *bio);
>
> 2. Return the virtual address by double pointer as below:
> int page_frag_alloc_bio(struct page_frag_cache *nc, struct bio_vec *bio,
>                         void **va);

I was thinking more of option 1. Basically this is a superset of
page_frag_alloc_va that is also returning the page and offset via a
page frag. However instead of bio_vec I would be good with "struct
page_frag *" being the value passed to the function to play the role
of container. Basically the big difference between 1 and 2/3 if I am
not mistaken is the fact that for 1 you pass the size, whereas with
2/3 you are peeling off the page frag from the larger page frag cache
after the fact via a commit type action.

Re: [PATCH net-next v13 04/14] mm: page_frag: add '_va' suffix to page_frag API

[Yunsheng Lin]

On 2024/8/19 23:54, Alexander Duyck wrote:

...

>>>>
>>>> "There are three types of API as proposed in this patchset instead of
>>>> two types of API:
>>>> 1. page_frag_alloc_va() returns [va].
>>>> 2. page_frag_alloc_pg() returns [page, offset].
>>>> 3. page_frag_alloc() returns [va] & [page, offset].
>>>>
>>>> You seemed to miss that we need a third naming for the type 3 API.
>>>> Do you see type 3 API as a valid API? if yes, what naming are you
>>>> suggesting for it? if no, why it is not a valid API?"
>>>
>>> I didn't. I just don't see the point in pushing out the existing API
>>> to support that. In reality 2 and 3 are redundant. You probably only
>>> need 3. Like I mentioned earlier you can essentially just pass a
>>
>> If the caller just expect [page, offset], do you expect the caller also
>> type 3 API, which return both [va] and [page, offset]?
>>
>> I am not sure if I understand why you think 2 and 3 are redundant here?
>> If you think 2 and 3 are redundant here, aren't 1 and 3 also redundant
>> as the similar agrument?
> 
> The big difference is the need to return page and offset. Basically to
> support returning page and offset you need to pass at least one value
> as a pointer so you can store the return there.
> 
> The reason why 3 is just a redundant form of 2 is that you will
> normally just be converting from a va to a page and offset so the va
> should already be easily accessible.

I am assuming that by 'easily accessible', you meant the 'va' can be
calculated as below, right?

va = encoded_page_address(encoded_va) +
		(page_frag_cache_page_size(encoded_va) - remaining);

I guess it is easily accessible, but it is not without some overhead
to calculate the 'va' here.

> 
>>> page_frag via pointer to the function. With that you could also look
>>> at just returning a virtual address as well if you insist on having
>>> something that returns all of the above. No point in having 2 and 3 be
>>> seperate functions.
>>
>> Let's be more specific about what are your suggestion here: which way
>> is the prefer way to return the virtual address. It seems there are two
>> options:
>>
>> 1. Return the virtual address by function returning as below:
>> void *page_frag_alloc_bio(struct page_frag_cache *nc, struct bio_vec *bio);
>>
>> 2. Return the virtual address by double pointer as below:
>> int page_frag_alloc_bio(struct page_frag_cache *nc, struct bio_vec *bio,
>>                         void **va);
> 
> I was thinking more of option 1. Basically this is a superset of
> page_frag_alloc_va that is also returning the page and offset via a
> page frag. However instead of bio_vec I would be good with "struct
> page_frag *" being the value passed to the function to play the role
> of container. Basically the big difference between 1 and 2/3 if I am
> not mistaken is the fact that for 1 you pass the size, whereas with
> 2/3 you are peeling off the page frag from the larger page frag cache

Let's be clear here: The callers just expecting [page, offset] also need
to call type 3 API, which return both [va] and [page, offset]? and it
is ok to ignore the overhead of calculating the 'va' for those kinds
of callers just because we don't want to do the renaming for a existing
API and can't come up with good naming for that?

> after the fact via a commit type action.

Just be clear here, there is no commit type action for some subtype of
type 2/3 API.

For example, for type 2 API in this patchset, it has below subtypes:

subtype 1: it does not need a commit type action, it just return
           [page, offset] instead of page_frag_alloc_va() returning [va],
           and it does not return the allocated fragsz back to the caller
           as page_frag_alloc_va() does not too:
struct page *page_frag_alloc_pg(struct page_frag_cache *nc,
                                unsigned int *offset, unsigned int fragsz,
                                gfp_t gfp)

subtype 2: it does need a commit type action, and @fragsz is returned to
           the caller and caller used that to commit how much fragsz to
           commit.
struct page *page_frag_alloc_pg_prepare(struct page_frag_cache *nc,
                                        unsigned int *offset,
                                        unsigned int *fragsz, gfp_t gfp)

Do you see subtype 1 as valid API? If no, why?
If yes, do you also expect the caller to use "struct page_frag *" as the
container? If yes, what is the caller expected to do with the size field in
"struct page_frag *" from API perspective? Just ignore it?

Re: [PATCH net-next v13 04/14] mm: page_frag: add '_va' suffix to page_frag API

[Alexander Duyck]

On Tue, Aug 20, 2024 at 6:07 AM Yunsheng Lin <linyunsheng@huawei.com> wrote:
>
> On 2024/8/19 23:54, Alexander Duyck wrote:
>
> ...
>
> >>>>
> >>>> "There are three types of API as proposed in this patchset instead of
> >>>> two types of API:
> >>>> 1. page_frag_alloc_va() returns [va].
> >>>> 2. page_frag_alloc_pg() returns [page, offset].
> >>>> 3. page_frag_alloc() returns [va] & [page, offset].
> >>>>
> >>>> You seemed to miss that we need a third naming for the type 3 API.
> >>>> Do you see type 3 API as a valid API? if yes, what naming are you
> >>>> suggesting for it? if no, why it is not a valid API?"
> >>>
> >>> I didn't. I just don't see the point in pushing out the existing API
> >>> to support that. In reality 2 and 3 are redundant. You probably only
> >>> need 3. Like I mentioned earlier you can essentially just pass a
> >>
> >> If the caller just expect [page, offset], do you expect the caller also
> >> type 3 API, which return both [va] and [page, offset]?
> >>
> >> I am not sure if I understand why you think 2 and 3 are redundant here?
> >> If you think 2 and 3 are redundant here, aren't 1 and 3 also redundant
> >> as the similar agrument?
> >
> > The big difference is the need to return page and offset. Basically to
> > support returning page and offset you need to pass at least one value
> > as a pointer so you can store the return there.
> >
> > The reason why 3 is just a redundant form of 2 is that you will
> > normally just be converting from a va to a page and offset so the va
> > should already be easily accessible.
>
> I am assuming that by 'easily accessible', you meant the 'va' can be
> calculated as below, right?
>
> va = encoded_page_address(encoded_va) +
>                 (page_frag_cache_page_size(encoded_va) - remaining);
>
> I guess it is easily accessible, but it is not without some overhead
> to calculate the 'va' here.

It is just the encoded_page_address + offset that you have to
calculate anyway. So the only bit you actually have to do is 2
instructions, one to mask the encoded_va and then the addition of the
offset that you provided to the page. As it stands those instruction
can easily be slipped in while you are working on converting the va to
a page.


> >
> >>> page_frag via pointer to the function. With that you could also look
> >>> at just returning a virtual address as well if you insist on having
> >>> something that returns all of the above. No point in having 2 and 3 be
> >>> seperate functions.
> >>
> >> Let's be more specific about what are your suggestion here: which way
> >> is the prefer way to return the virtual address. It seems there are two
> >> options:
> >>
> >> 1. Return the virtual address by function returning as below:
> >> void *page_frag_alloc_bio(struct page_frag_cache *nc, struct bio_vec *bio);
> >>
> >> 2. Return the virtual address by double pointer as below:
> >> int page_frag_alloc_bio(struct page_frag_cache *nc, struct bio_vec *bio,
> >>                         void **va);
> >
> > I was thinking more of option 1. Basically this is a superset of
> > page_frag_alloc_va that is also returning the page and offset via a
> > page frag. However instead of bio_vec I would be good with "struct
> > page_frag *" being the value passed to the function to play the role
> > of container. Basically the big difference between 1 and 2/3 if I am
> > not mistaken is the fact that for 1 you pass the size, whereas with
> > 2/3 you are peeling off the page frag from the larger page frag cache
>
> Let's be clear here: The callers just expecting [page, offset] also need
> to call type 3 API, which return both [va] and [page, offset]? and it
> is ok to ignore the overhead of calculating the 'va' for those kinds
> of callers just because we don't want to do the renaming for a existing
> API and can't come up with good naming for that?
>
> > after the fact via a commit type action.
>
> Just be clear here, there is no commit type action for some subtype of
> type 2/3 API.
>
> For example, for type 2 API in this patchset, it has below subtypes:
>
> subtype 1: it does not need a commit type action, it just return
>            [page, offset] instead of page_frag_alloc_va() returning [va],
>            and it does not return the allocated fragsz back to the caller
>            as page_frag_alloc_va() does not too:
> struct page *page_frag_alloc_pg(struct page_frag_cache *nc,
>                                 unsigned int *offset, unsigned int fragsz,
>                                 gfp_t gfp)
>
> subtype 2: it does need a commit type action, and @fragsz is returned to
>            the caller and caller used that to commit how much fragsz to
>            commit.
> struct page *page_frag_alloc_pg_prepare(struct page_frag_cache *nc,
>                                         unsigned int *offset,
>                                         unsigned int *fragsz, gfp_t gfp)
>
> Do you see subtype 1 as valid API? If no, why?

Not really, it is just a wrapper for page_frag_alloc that is
converting the virtual address to a page and offset. They are the same
data and don't justify the need for two functions. It kind of explains
one of the complaints I had about this code. Supposedly it was
refactoring and combining several different callers into one, but what
it is actually doing is fracturing the code path into 3 different
variants based on little if any actual difference as it is doing
unnecessary optimization.

> If yes, do you also expect the caller to use "struct page_frag *" as the
> container? If yes, what is the caller expected to do with the size field in
> "struct page_frag *" from API perspective? Just ignore it?

It should be populated. You passed a fragsz, so you should populate
the output fragsz so you can get the truesize in the case of network
packets. The removal of the page_frag from the other callers is making
it much harder to review your code anyway. If we keep the page_frag
there it should reduce the amount of change needed when you replace
page_frag with the page_frag_cache.

Honestly this is eating up too much of my time. As I said before this
patch set is too big and it is trying to squeeze in more than it
really should for a single patch set to be reviewable. Going forward
please split up the patch set as I had suggested before and address my
comments. Ideally you would have your first patch just be some
refactor and cleanup to get the "offset" pointer moving in the
direction you want. With that we can at least get half of this set
digested before we start chewing into all this refactor for the
replacement of page_frag with the page_frag_cache.

Re: [PATCH net-next v13 04/14] mm: page_frag: add '_va' suffix to page_frag API

[Yunsheng Lin]

On 2024/8/21 0:02, Alexander Duyck wrote:
> On Tue, Aug 20, 2024 at 6:07 AM Yunsheng Lin <linyunsheng@huawei.com> wrote:
>>
>> On 2024/8/19 23:54, Alexander Duyck wrote:
>>
>> ...
>>
>>>>>>
>>>>>> "There are three types of API as proposed in this patchset instead of
>>>>>> two types of API:
>>>>>> 1. page_frag_alloc_va() returns [va].
>>>>>> 2. page_frag_alloc_pg() returns [page, offset].
>>>>>> 3. page_frag_alloc() returns [va] & [page, offset].
>>>>>>
>>>>>> You seemed to miss that we need a third naming for the type 3 API.
>>>>>> Do you see type 3 API as a valid API? if yes, what naming are you
>>>>>> suggesting for it? if no, why it is not a valid API?"
>>>>>
>>>>> I didn't. I just don't see the point in pushing out the existing API
>>>>> to support that. In reality 2 and 3 are redundant. You probably only
>>>>> need 3. Like I mentioned earlier you can essentially just pass a
>>>>
>>>> If the caller just expect [page, offset], do you expect the caller also
>>>> type 3 API, which return both [va] and [page, offset]?
>>>>
>>>> I am not sure if I understand why you think 2 and 3 are redundant here?
>>>> If you think 2 and 3 are redundant here, aren't 1 and 3 also redundant
>>>> as the similar agrument?
>>>
>>> The big difference is the need to return page and offset. Basically to
>>> support returning page and offset you need to pass at least one value
>>> as a pointer so you can store the return there.
>>>
>>> The reason why 3 is just a redundant form of 2 is that you will
>>> normally just be converting from a va to a page and offset so the va
>>> should already be easily accessible.
>>
>> I am assuming that by 'easily accessible', you meant the 'va' can be
>> calculated as below, right?
>>
>> va = encoded_page_address(encoded_va) +
>>                 (page_frag_cache_page_size(encoded_va) - remaining);
>>
>> I guess it is easily accessible, but it is not without some overhead
>> to calculate the 'va' here.
> 
> It is just the encoded_page_address + offset that you have to
> calculate anyway. So the only bit you actually have to do is 2
> instructions, one to mask the encoded_va and then the addition of the
> offset that you provided to the page. As it stands those instruction
> can easily be slipped in while you are working on converting the va to
> a page.

Well, with your suggestions against other optimizations like avoiding
a checking in fast patch and avoid calling virt_to_page(), the overhead
is kind of added up.

And I am really surprised by your above suggestion about deciding the
API for users according to the internal implementation detail here. As
the overhead of calculating 'va' is really depending on the layout of
'struct page_frag_cache' here, what if we change the implementation and
the overhead of calculating 'va' becomes bigger? Do we expect to change
the API for the callers when we change the internal implementation of
page_frag_cache?

> 
> 
>>>
>>>>> page_frag via pointer to the function. With that you could also look
>>>>> at just returning a virtual address as well if you insist on having
>>>>> something that returns all of the above. No point in having 2 and 3 be
>>>>> seperate functions.
>>>>
>>>> Let's be more specific about what are your suggestion here: which way
>>>> is the prefer way to return the virtual address. It seems there are two
>>>> options:
>>>>
>>>> 1. Return the virtual address by function returning as below:
>>>> void *page_frag_alloc_bio(struct page_frag_cache *nc, struct bio_vec *bio);
>>>>
>>>> 2. Return the virtual address by double pointer as below:
>>>> int page_frag_alloc_bio(struct page_frag_cache *nc, struct bio_vec *bio,
>>>>                         void **va);
>>>
>>> I was thinking more of option 1. Basically this is a superset of
>>> page_frag_alloc_va that is also returning the page and offset via a
>>> page frag. However instead of bio_vec I would be good with "struct
>>> page_frag *" being the value passed to the function to play the role
>>> of container. Basically the big difference between 1 and 2/3 if I am
>>> not mistaken is the fact that for 1 you pass the size, whereas with
>>> 2/3 you are peeling off the page frag from the larger page frag cache
>>
>> Let's be clear here: The callers just expecting [page, offset] also need
>> to call type 3 API, which return both [va] and [page, offset]? and it
>> is ok to ignore the overhead of calculating the 'va' for those kinds
>> of callers just because we don't want to do the renaming for a existing
>> API and can't come up with good naming for that?
>>
>>> after the fact via a commit type action.
>>
>> Just be clear here, there is no commit type action for some subtype of
>> type 2/3 API.
>>
>> For example, for type 2 API in this patchset, it has below subtypes:
>>
>> subtype 1: it does not need a commit type action, it just return
>>            [page, offset] instead of page_frag_alloc_va() returning [va],
>>            and it does not return the allocated fragsz back to the caller
>>            as page_frag_alloc_va() does not too:
>> struct page *page_frag_alloc_pg(struct page_frag_cache *nc,
>>                                 unsigned int *offset, unsigned int fragsz,
>>                                 gfp_t gfp)
>>
>> subtype 2: it does need a commit type action, and @fragsz is returned to
>>            the caller and caller used that to commit how much fragsz to
>>            commit.
>> struct page *page_frag_alloc_pg_prepare(struct page_frag_cache *nc,
>>                                         unsigned int *offset,
>>                                         unsigned int *fragsz, gfp_t gfp)
>>
>> Do you see subtype 1 as valid API? If no, why?
> 
> Not really, it is just a wrapper for page_frag_alloc that is
> converting the virtual address to a page and offset. They are the same
> data and don't justify the need for two functions. It kind of explains

I am supposing you meant something like below:
struct page *page_frag_alloc_pg(struct page_frag_cache *nc,
				unsigned int *offset, unsigned int fragsz,
				gfp_t gfp)
{
	struct page *page;
	void *va;

	va = page_frag_alloc_va(nc, fragsz, gfp);
	if (!va)
		return NULL;

	page = virt_to_head_page(va);
	*offset = va - page_to_virt(page);

	return page;
}

If yes, I really think you are caring about maintainability too much by
trading off too much performance here by not only recalculating the offset
here, but also sometimes calling virt_to_head_page() unnecessarily.

If no, please share the pseudo code in your mind.

> one of the complaints I had about this code. Supposedly it was
> refactoring and combining several different callers into one, but what
> it is actually doing is fracturing the code path into 3 different
> variants based on little if any actual difference as it is doing
> unnecessary optimization.

I am supposing the 3 different variants meant the below, right?
1. page_frag_alloc_va() returns [va].
2. page_frag_alloc_pg() returns [page, offset].
3. page_frag_alloc() returns [va] & [page, offset].

And there is others 3 different variants for prepare API too:
4. page_frag_alloc_va_prepare() returns [va].
5. page_frag_alloc_pg_prepare() returns [page, offset].
6. page_frag_alloc_prepare() returns [va] & [page, offset].

Side note: I just found the '4. page_frag_alloc_va_prepare()' API is
not used/called currently and can be removed in next revision for this
patchset.

It seems what you really want is 3 & 2 to be a wrapper for 1, and
5 & 6 to be a wrapper for 4?

If yes, too much performance is traded off here as my understanding.
Does't the introducing of __page_frag_cache_reload() already enable the
balance between performance and maintainability as much as possible in
patch 8?

> 
>> If yes, do you also expect the caller to use "struct page_frag *" as the
>> container? If yes, what is the caller expected to do with the size field in
>> "struct page_frag *" from API perspective? Just ignore it?
> 
> It should be populated. You passed a fragsz, so you should populate
> the output fragsz so you can get the truesize in the case of network
> packets. The removal of the page_frag from the other callers is making
> it much harder to review your code anyway. If we keep the page_frag
> there it should reduce the amount of change needed when you replace
> page_frag with the page_frag_cache.

I am not starting to use page_frag as the container yet, but the above
part is something that I am probably agreed with.

> 
> Honestly this is eating up too much of my time. As I said before this
> patch set is too big and it is trying to squeeze in more than it
> really should for a single patch set to be reviewable. Going forward
> please split up the patch set as I had suggested before and address my
> comments. Ideally you would have your first patch just be some
> refactor and cleanup to get the "offset" pointer moving in the
> direction you want. With that we can at least get half of this set
> digested before we start chewing into all this refactor for the
> replacement of page_frag with the page_frag_cache.

I don't really think breaking this patchset into more patchsets without
a newcase is helping to speed up the process here, it might slow down
the process instead, as the different idea about the refactoring and
new API naming is not going to disappear by breaking the patchset, and
the breaking may make the discussion harder without a bigger picture
and context.

Re: [PATCH net-next v13 07/14] mm: page_frag: reuse existing space for 'size' and 'pfmemalloc'

[Alexander H Duyck]

On Thu, 2024-08-08 at 20:37 +0800, Yunsheng Lin wrote:
> Currently there is one 'struct page_frag' for every 'struct
> sock' and 'struct task_struct', we are about to replace the
> 'struct page_frag' with 'struct page_frag_cache' for them.
> Before begin the replacing, we need to ensure the size of
> 'struct page_frag_cache' is not bigger than the size of
> 'struct page_frag', as there may be tens of thousands of
> 'struct sock' and 'struct task_struct' instances in the
> system.
> 
> By or'ing the page order & pfmemalloc with lower bits of
> 'va' instead of using 'u16' or 'u32' for page size and 'u8'
> for pfmemalloc, we are able to avoid 3 or 5 bytes space waste.
> And page address & pfmemalloc & order is unchanged for the
> same page in the same 'page_frag_cache' instance, it makes
> sense to fit them together.
> 
> After this patch, the size of 'struct page_frag_cache' should be
> the same as the size of 'struct page_frag'.
> 
> CC: Alexander Duyck <alexander.duyck@gmail.com>
> Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
> ---
>  include/linux/mm_types_task.h   | 16 +++++-----
>  include/linux/page_frag_cache.h | 52 +++++++++++++++++++++++++++++++--
>  mm/page_frag_cache.c            | 49 +++++++++++++++++--------------
>  3 files changed, 85 insertions(+), 32 deletions(-)
> 
> diff --git a/include/linux/mm_types_task.h b/include/linux/mm_types_task.h
> index b1c54b2b9308..f2610112a642 100644
> --- a/include/linux/mm_types_task.h
> +++ b/include/linux/mm_types_task.h
> @@ -50,18 +50,18 @@ struct page_frag {
>  #define PAGE_FRAG_CACHE_MAX_SIZE	__ALIGN_MASK(32768, ~PAGE_MASK)
>  #define PAGE_FRAG_CACHE_MAX_ORDER	get_order(PAGE_FRAG_CACHE_MAX_SIZE)
>  struct page_frag_cache {
> -	void *va;
> -#if (PAGE_SIZE < PAGE_FRAG_CACHE_MAX_SIZE)
> +	/* encoded_va consists of the virtual address, pfmemalloc bit and order
> +	 * of a page.
> +	 */
> +	unsigned long encoded_va;
> +

Rather than calling this an "encoded_va" we might want to call this an
"encoded_page" as that would be closer to what we are actually working
with. We are just using the virtual address as the page pointer instead
of the page struct itself since we need quicker access to the virtual
address than we do the page struct.

> +#if (PAGE_SIZE < PAGE_FRAG_CACHE_MAX_SIZE) && (BITS_PER_LONG <= 32)
>  	__u16 remaining;
> -	__u16 size;
> +	__u16 pagecnt_bias;
>  #else
>  	__u32 remaining;
> +	__u32 pagecnt_bias;
>  #endif
> -	/* we maintain a pagecount bias, so that we dont dirty cache line
> -	 * containing page->_refcount every time we allocate a fragment.
> -	 */
> -	unsigned int		pagecnt_bias;
> -	bool pfmemalloc;
>  };
>  
>  /* Track pages that require TLB flushes */
> diff --git a/include/linux/page_frag_cache.h b/include/linux/page_frag_cache.h
> index 7c9125a9aed3..4ce924eaf1b1 100644
> --- a/include/linux/page_frag_cache.h
> +++ b/include/linux/page_frag_cache.h
> @@ -3,18 +3,66 @@
>  #ifndef _LINUX_PAGE_FRAG_CACHE_H
>  #define _LINUX_PAGE_FRAG_CACHE_H
>  
> +#include <linux/bits.h>
> +#include <linux/build_bug.h>
>  #include <linux/log2.h>
>  #include <linux/types.h>
>  #include <linux/mm_types_task.h>
>  
> +#if (PAGE_SIZE < PAGE_FRAG_CACHE_MAX_SIZE)
> +/* Use a full byte here to enable assembler optimization as the shift
> + * operation is usually expecting a byte.
> + */
> +#define PAGE_FRAG_CACHE_ORDER_MASK		GENMASK(7, 0)
> +#define PAGE_FRAG_CACHE_PFMEMALLOC_BIT		BIT(8)
> +#define PAGE_FRAG_CACHE_PFMEMALLOC_SHIFT	8
> +#else
> +/* Compiler should be able to figure out we don't read things as any value
> + * ANDed with 0 is 0.
> + */
> +#define PAGE_FRAG_CACHE_ORDER_MASK		0
> +#define PAGE_FRAG_CACHE_PFMEMALLOC_BIT		BIT(0)
> +#define PAGE_FRAG_CACHE_PFMEMALLOC_SHIFT	0
> +#endif
> +

You should probably pull out PAGE_FRAG_CACHE_PFMEMALLOC_BIT and just
define it as:
#define PAGE_FRAG_CACHE_PFMEMALLOC_BIT \
	BIT(PAGE_FRAG_CACHE_PFMEMALLOC_SHIFT)

That way there is no risk of the bit and the shift somehow getting
split up and being different values.

> +static inline unsigned long encode_aligned_va(void *va, unsigned int order,
> +					      bool pfmemalloc)

Rather than passing the virtual address it might make more sense to
pass the page. With that you know it should be PAGE_SIZE aligned versus
just being passed some random virtual address.

> +{
> +	BUILD_BUG_ON(PAGE_FRAG_CACHE_MAX_ORDER > PAGE_FRAG_CACHE_ORDER_MASK);
> +	BUILD_BUG_ON(PAGE_FRAG_CACHE_PFMEMALLOC_SHIFT >= PAGE_SHIFT);

Rather than test the shift I would test the bit versus PAGE_SIZE.

> +
> +	return (unsigned long)va | (order & PAGE_FRAG_CACHE_ORDER_MASK) |
> +		((unsigned long)pfmemalloc << PAGE_FRAG_CACHE_PFMEMALLOC_SHIFT);
> +}
> +
> +static inline unsigned long encoded_page_order(unsigned long encoded_va)
> +{
> +	return encoded_va & PAGE_FRAG_CACHE_ORDER_MASK;
> +}
> +
> +static inline bool encoded_page_pfmemalloc(unsigned long encoded_va)
> +{
> +	return !!(encoded_va & PAGE_FRAG_CACHE_PFMEMALLOC_BIT);
> +}
> +
> +static inline void *encoded_page_address(unsigned long encoded_va)
> +{
> +	return (void *)(encoded_va & PAGE_MASK);
> +}
> +

This is one of the reasons why I am thinking "encoded_page" might be a
better name for it. The 3 functions above all have their equivilent for
a page struct but we pulled that data out and packed it all into the
encoded_page.

Re: [PATCH net-next v13 07/14] mm: page_frag: reuse existing space for 'size' and 'pfmemalloc'

[Yunsheng Lin]

On 2024/8/15 0:13, Alexander H Duyck wrote:
> On Thu, 2024-08-08 at 20:37 +0800, Yunsheng Lin wrote:
>> Currently there is one 'struct page_frag' for every 'struct
>> sock' and 'struct task_struct', we are about to replace the
>> 'struct page_frag' with 'struct page_frag_cache' for them.
>> Before begin the replacing, we need to ensure the size of
>> 'struct page_frag_cache' is not bigger than the size of
>> 'struct page_frag', as there may be tens of thousands of
>> 'struct sock' and 'struct task_struct' instances in the
>> system.
>>
>> By or'ing the page order & pfmemalloc with lower bits of
>> 'va' instead of using 'u16' or 'u32' for page size and 'u8'
>> for pfmemalloc, we are able to avoid 3 or 5 bytes space waste.
>> And page address & pfmemalloc & order is unchanged for the
>> same page in the same 'page_frag_cache' instance, it makes
>> sense to fit them together.
>>
>> After this patch, the size of 'struct page_frag_cache' should be
>> the same as the size of 'struct page_frag'.
>>
>> CC: Alexander Duyck <alexander.duyck@gmail.com>
>> Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
>> ---
>>  include/linux/mm_types_task.h   | 16 +++++-----
>>  include/linux/page_frag_cache.h | 52 +++++++++++++++++++++++++++++++--
>>  mm/page_frag_cache.c            | 49 +++++++++++++++++--------------
>>  3 files changed, 85 insertions(+), 32 deletions(-)
>>
>> diff --git a/include/linux/mm_types_task.h b/include/linux/mm_types_task.h
>> index b1c54b2b9308..f2610112a642 100644
>> --- a/include/linux/mm_types_task.h
>> +++ b/include/linux/mm_types_task.h
>> @@ -50,18 +50,18 @@ struct page_frag {
>>  #define PAGE_FRAG_CACHE_MAX_SIZE	__ALIGN_MASK(32768, ~PAGE_MASK)
>>  #define PAGE_FRAG_CACHE_MAX_ORDER	get_order(PAGE_FRAG_CACHE_MAX_SIZE)
>>  struct page_frag_cache {
>> -	void *va;
>> -#if (PAGE_SIZE < PAGE_FRAG_CACHE_MAX_SIZE)
>> +	/* encoded_va consists of the virtual address, pfmemalloc bit and order
>> +	 * of a page.
>> +	 */
>> +	unsigned long encoded_va;
>> +
> 
> Rather than calling this an "encoded_va" we might want to call this an
> "encoded_page" as that would be closer to what we are actually working
> with. We are just using the virtual address as the page pointer instead
> of the page struct itself since we need quicker access to the virtual
> address than we do the page struct.

Calling it "encoded_page" seems confusing enough when calling virt_to_page()
with "encoded_page" when virt_to_page() is expecting a 'va', no?

> 

Re: [PATCH net-next v13 07/14] mm: page_frag: reuse existing space for 'size' and 'pfmemalloc'

[Alexander Duyck]

On Wed, Aug 14, 2024 at 8:10 PM Yunsheng Lin <linyunsheng@huawei.com> wrote:
>
> On 2024/8/15 0:13, Alexander H Duyck wrote:
> > On Thu, 2024-08-08 at 20:37 +0800, Yunsheng Lin wrote:
> >> Currently there is one 'struct page_frag' for every 'struct
> >> sock' and 'struct task_struct', we are about to replace the
> >> 'struct page_frag' with 'struct page_frag_cache' for them.
> >> Before begin the replacing, we need to ensure the size of
> >> 'struct page_frag_cache' is not bigger than the size of
> >> 'struct page_frag', as there may be tens of thousands of
> >> 'struct sock' and 'struct task_struct' instances in the
> >> system.
> >>
> >> By or'ing the page order & pfmemalloc with lower bits of
> >> 'va' instead of using 'u16' or 'u32' for page size and 'u8'
> >> for pfmemalloc, we are able to avoid 3 or 5 bytes space waste.
> >> And page address & pfmemalloc & order is unchanged for the
> >> same page in the same 'page_frag_cache' instance, it makes
> >> sense to fit them together.
> >>
> >> After this patch, the size of 'struct page_frag_cache' should be
> >> the same as the size of 'struct page_frag'.
> >>
> >> CC: Alexander Duyck <alexander.duyck@gmail.com>
> >> Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
> >> ---
> >>  include/linux/mm_types_task.h   | 16 +++++-----
> >>  include/linux/page_frag_cache.h | 52 +++++++++++++++++++++++++++++++--
> >>  mm/page_frag_cache.c            | 49 +++++++++++++++++--------------
> >>  3 files changed, 85 insertions(+), 32 deletions(-)
> >>
> >> diff --git a/include/linux/mm_types_task.h b/include/linux/mm_types_task.h
> >> index b1c54b2b9308..f2610112a642 100644
> >> --- a/include/linux/mm_types_task.h
> >> +++ b/include/linux/mm_types_task.h
> >> @@ -50,18 +50,18 @@ struct page_frag {
> >>  #define PAGE_FRAG_CACHE_MAX_SIZE    __ALIGN_MASK(32768, ~PAGE_MASK)
> >>  #define PAGE_FRAG_CACHE_MAX_ORDER   get_order(PAGE_FRAG_CACHE_MAX_SIZE)
> >>  struct page_frag_cache {
> >> -    void *va;
> >> -#if (PAGE_SIZE < PAGE_FRAG_CACHE_MAX_SIZE)
> >> +    /* encoded_va consists of the virtual address, pfmemalloc bit and order
> >> +     * of a page.
> >> +     */
> >> +    unsigned long encoded_va;
> >> +
> >
> > Rather than calling this an "encoded_va" we might want to call this an
> > "encoded_page" as that would be closer to what we are actually working
> > with. We are just using the virtual address as the page pointer instead
> > of the page struct itself since we need quicker access to the virtual
> > address than we do the page struct.
>
> Calling it "encoded_page" seems confusing enough when calling virt_to_page()
> with "encoded_page" when virt_to_page() is expecting a 'va', no?

It makes about as much sense as calling it an "encoded_va". What you
have is essentially a packed page struct that contains the virtual
address, pfmemalloc flag, and order. So if you want you could call it
"packed_page" too I suppose. Basically this isn't a valid virtual
address it is a page pointer with some extra metadata packed in.

Re: [PATCH net-next v13 07/14] mm: page_frag: reuse existing space for 'size' and 'pfmemalloc'

[Yunsheng Lin]

On 2024/8/15 23:03, Alexander Duyck wrote:
> On Wed, Aug 14, 2024 at 8:10 PM Yunsheng Lin <linyunsheng@huawei.com> wrote:
>>
>> On 2024/8/15 0:13, Alexander H Duyck wrote:
>>> On Thu, 2024-08-08 at 20:37 +0800, Yunsheng Lin wrote:
>>>> Currently there is one 'struct page_frag' for every 'struct
>>>> sock' and 'struct task_struct', we are about to replace the
>>>> 'struct page_frag' with 'struct page_frag_cache' for them.
>>>> Before begin the replacing, we need to ensure the size of
>>>> 'struct page_frag_cache' is not bigger than the size of
>>>> 'struct page_frag', as there may be tens of thousands of
>>>> 'struct sock' and 'struct task_struct' instances in the
>>>> system.
>>>>
>>>> By or'ing the page order & pfmemalloc with lower bits of
>>>> 'va' instead of using 'u16' or 'u32' for page size and 'u8'
>>>> for pfmemalloc, we are able to avoid 3 or 5 bytes space waste.
>>>> And page address & pfmemalloc & order is unchanged for the
>>>> same page in the same 'page_frag_cache' instance, it makes
>>>> sense to fit them together.
>>>>
>>>> After this patch, the size of 'struct page_frag_cache' should be
>>>> the same as the size of 'struct page_frag'.
>>>>
>>>> CC: Alexander Duyck <alexander.duyck@gmail.com>
>>>> Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
>>>> ---
>>>>  include/linux/mm_types_task.h   | 16 +++++-----
>>>>  include/linux/page_frag_cache.h | 52 +++++++++++++++++++++++++++++++--
>>>>  mm/page_frag_cache.c            | 49 +++++++++++++++++--------------
>>>>  3 files changed, 85 insertions(+), 32 deletions(-)
>>>>
>>>> diff --git a/include/linux/mm_types_task.h b/include/linux/mm_types_task.h
>>>> index b1c54b2b9308..f2610112a642 100644
>>>> --- a/include/linux/mm_types_task.h
>>>> +++ b/include/linux/mm_types_task.h
>>>> @@ -50,18 +50,18 @@ struct page_frag {
>>>>  #define PAGE_FRAG_CACHE_MAX_SIZE    __ALIGN_MASK(32768, ~PAGE_MASK)
>>>>  #define PAGE_FRAG_CACHE_MAX_ORDER   get_order(PAGE_FRAG_CACHE_MAX_SIZE)
>>>>  struct page_frag_cache {
>>>> -    void *va;
>>>> -#if (PAGE_SIZE < PAGE_FRAG_CACHE_MAX_SIZE)
>>>> +    /* encoded_va consists of the virtual address, pfmemalloc bit and order
>>>> +     * of a page.
>>>> +     */
>>>> +    unsigned long encoded_va;
>>>> +
>>>
>>> Rather than calling this an "encoded_va" we might want to call this an
>>> "encoded_page" as that would be closer to what we are actually working
>>> with. We are just using the virtual address as the page pointer instead
>>> of the page struct itself since we need quicker access to the virtual
>>> address than we do the page struct.
>>
>> Calling it "encoded_page" seems confusing enough when calling virt_to_page()
>> with "encoded_page" when virt_to_page() is expecting a 'va', no?
> 
> It makes about as much sense as calling it an "encoded_va". What you
> have is essentially a packed page struct that contains the virtual
> address, pfmemalloc flag, and order. So if you want you could call it
> "packed_page" too I suppose. Basically this isn't a valid virtual
> address it is a page pointer with some extra metadata packed in.

I think we are all argeed that is not a valid virtual address by adding
the 'encoded_' part.
I am not really sure if "encoded_page" or "packed_page" is better than
'encoded_va' here, as there is no 'page pointer' that is implied by
"encoded_page" or "packed_page" here. For 'encoded_va', at least there
is 'virtual address' that is implied by 'encoded_va', and that 'virtual
address' just happen to be page pointer.

Yes, you may say the 'pfmemalloc flag and order' part is about page, not
about 'va', I guess there is trade-off we need to make here if there is
not a perfect name for it and 'va' does occupy most bits of 'encoded_va'.

Re: [PATCH net-next v13 07/14] mm: page_frag: reuse existing space for 'size' and 'pfmemalloc'

[Alexander Duyck]

On Fri, Aug 16, 2024 at 4:56 AM Yunsheng Lin <linyunsheng@huawei.com> wrote:
>
> On 2024/8/15 23:03, Alexander Duyck wrote:
> > On Wed, Aug 14, 2024 at 8:10 PM Yunsheng Lin <linyunsheng@huawei.com> wrote:
> >>
> >> On 2024/8/15 0:13, Alexander H Duyck wrote:
> >>> On Thu, 2024-08-08 at 20:37 +0800, Yunsheng Lin wrote:
> >>>> Currently there is one 'struct page_frag' for every 'struct
> >>>> sock' and 'struct task_struct', we are about to replace the
> >>>> 'struct page_frag' with 'struct page_frag_cache' for them.
> >>>> Before begin the replacing, we need to ensure the size of
> >>>> 'struct page_frag_cache' is not bigger than the size of
> >>>> 'struct page_frag', as there may be tens of thousands of
> >>>> 'struct sock' and 'struct task_struct' instances in the
> >>>> system.
> >>>>
> >>>> By or'ing the page order & pfmemalloc with lower bits of
> >>>> 'va' instead of using 'u16' or 'u32' for page size and 'u8'
> >>>> for pfmemalloc, we are able to avoid 3 or 5 bytes space waste.
> >>>> And page address & pfmemalloc & order is unchanged for the
> >>>> same page in the same 'page_frag_cache' instance, it makes
> >>>> sense to fit them together.
> >>>>
> >>>> After this patch, the size of 'struct page_frag_cache' should be
> >>>> the same as the size of 'struct page_frag'.
> >>>>
> >>>> CC: Alexander Duyck <alexander.duyck@gmail.com>
> >>>> Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
> >>>> ---
> >>>>  include/linux/mm_types_task.h   | 16 +++++-----
> >>>>  include/linux/page_frag_cache.h | 52 +++++++++++++++++++++++++++++++--
> >>>>  mm/page_frag_cache.c            | 49 +++++++++++++++++--------------
> >>>>  3 files changed, 85 insertions(+), 32 deletions(-)
> >>>>
> >>>> diff --git a/include/linux/mm_types_task.h b/include/linux/mm_types_task.h
> >>>> index b1c54b2b9308..f2610112a642 100644
> >>>> --- a/include/linux/mm_types_task.h
> >>>> +++ b/include/linux/mm_types_task.h
> >>>> @@ -50,18 +50,18 @@ struct page_frag {
> >>>>  #define PAGE_FRAG_CACHE_MAX_SIZE    __ALIGN_MASK(32768, ~PAGE_MASK)
> >>>>  #define PAGE_FRAG_CACHE_MAX_ORDER   get_order(PAGE_FRAG_CACHE_MAX_SIZE)
> >>>>  struct page_frag_cache {
> >>>> -    void *va;
> >>>> -#if (PAGE_SIZE < PAGE_FRAG_CACHE_MAX_SIZE)
> >>>> +    /* encoded_va consists of the virtual address, pfmemalloc bit and order
> >>>> +     * of a page.
> >>>> +     */
> >>>> +    unsigned long encoded_va;
> >>>> +
> >>>
> >>> Rather than calling this an "encoded_va" we might want to call this an
> >>> "encoded_page" as that would be closer to what we are actually working
> >>> with. We are just using the virtual address as the page pointer instead
> >>> of the page struct itself since we need quicker access to the virtual
> >>> address than we do the page struct.
> >>
> >> Calling it "encoded_page" seems confusing enough when calling virt_to_page()
> >> with "encoded_page" when virt_to_page() is expecting a 'va', no?
> >
> > It makes about as much sense as calling it an "encoded_va". What you
> > have is essentially a packed page struct that contains the virtual
> > address, pfmemalloc flag, and order. So if you want you could call it
> > "packed_page" too I suppose. Basically this isn't a valid virtual
> > address it is a page pointer with some extra metadata packed in.
>
> I think we are all argeed that is not a valid virtual address by adding
> the 'encoded_' part.
> I am not really sure if "encoded_page" or "packed_page" is better than
> 'encoded_va' here, as there is no 'page pointer' that is implied by
> "encoded_page" or "packed_page" here. For 'encoded_va', at least there
> is 'virtual address' that is implied by 'encoded_va', and that 'virtual
> address' just happen to be page pointer.

Basically we are using the page's virtual address to encode the page
into the struct. If you look, "virtual" is a pointer stored in the
page to provide the virtual address on some architectures. It also
happens that we have virt_to_page which provides an easy way to get
back and forth between the values.

> Yes, you may say the 'pfmemalloc flag and order' part is about page, not
> about 'va', I guess there is trade-off we need to make here if there is
> not a perfect name for it and 'va' does occupy most bits of 'encoded_va'.

The naming isn't really a show stopper one way or another. It was more
the fact that you had several functions accessing it that were using
the name "encoded_page" as I recall. That is why I thought it might
make sense to rename it to that. Why have functions called
"encoded_page_order" work with an "encoded_va" versus an
"encoded_page". It makes it easier to logically lump them all
together.

Re: [PATCH net-next v13 08/14] mm: page_frag: some minor refactoring before adding new API

[Alexander H Duyck]

On Thu, 2024-08-08 at 20:37 +0800, Yunsheng Lin wrote:
> Refactor common codes from __page_frag_alloc_va_align()
> to __page_frag_cache_reload(), so that the new API can
> make use of them.
> 
> CC: Alexander Duyck <alexander.duyck@gmail.com>
> Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
> ---
>  include/linux/page_frag_cache.h |   2 +-
>  mm/page_frag_cache.c            | 138 ++++++++++++++++++--------------
>  2 files changed, 81 insertions(+), 59 deletions(-)
> 
> diff --git a/include/linux/page_frag_cache.h b/include/linux/page_frag_cache.h
> index 4ce924eaf1b1..0abffdd10a1c 100644
> --- a/include/linux/page_frag_cache.h
> +++ b/include/linux/page_frag_cache.h
> @@ -52,7 +52,7 @@ static inline void *encoded_page_address(unsigned long encoded_va)
>  
>  static inline void page_frag_cache_init(struct page_frag_cache *nc)
>  {
> -	nc->encoded_va = 0;
> +	memset(nc, 0, sizeof(*nc));
>  }
>  

Still not a fan of this. Just setting encoded_va to 0 should be enough
as the other fields will automatically be overwritten when the new page
is allocated.

Relying on memset is problematic at best since you then introduce the
potential for issues where remaining somehow gets corrupted but
encoded_va/page is 0. I would rather have both of these being checked
as a part of allocation than just just assuming it is valid if
remaining is set.

I would prefer to keep the check for a non-0 encoded_page value and
then check remaining rather than just rely on remaining as it creates a
single point of failure. With that we can safely tear away a page and
the next caller to try to allocate will populated a new page and the
associated fields.

>  static inline bool page_frag_cache_is_pfmemalloc(struct page_frag_cache *nc)
> diff --git a/mm/page_frag_cache.c b/mm/page_frag_cache.c
> index 2544b292375a..4e6b1c4684f0 100644
> --- a/mm/page_frag_cache.c
> +++ b/mm/page_frag_cache.c
> @@ -19,8 +19,27 @@
>  #include <linux/page_frag_cache.h>
>  #include "internal.h"
>  
> -static struct page *__page_frag_cache_refill(struct page_frag_cache *nc,
> -					     gfp_t gfp_mask)
> +static bool __page_frag_cache_reuse(unsigned long encoded_va,
> +				    unsigned int pagecnt_bias)
> +{
> +	struct page *page;
> +
> +	page = virt_to_page((void *)encoded_va);
> +	if (!page_ref_sub_and_test(page, pagecnt_bias))
> +		return false;
> +
> +	if (unlikely(encoded_page_pfmemalloc(encoded_va))) {
> +		free_unref_page(page, encoded_page_order(encoded_va));
> +		return false;
> +	}
> +
> +	/* OK, page count is 0, we can safely set it */
> +	set_page_count(page, PAGE_FRAG_CACHE_MAX_SIZE + 1);
> +	return true;
> +}
> +
> +static bool __page_frag_cache_refill(struct page_frag_cache *nc,
> +				     gfp_t gfp_mask)
>  {
>  	unsigned long order = PAGE_FRAG_CACHE_MAX_ORDER;
>  	struct page *page = NULL;
> @@ -35,8 +54,8 @@ static struct page *__page_frag_cache_refill(struct page_frag_cache *nc,
>  	if (unlikely(!page)) {
>  		page = alloc_pages_node(NUMA_NO_NODE, gfp, 0);
>  		if (unlikely(!page)) {
> -			nc->encoded_va = 0;
> -			return NULL;
> +			memset(nc, 0, sizeof(*nc));
> +			return false;
>  		}
>  
>  		order = 0;
> @@ -45,7 +64,33 @@ static struct page *__page_frag_cache_refill(struct page_frag_cache *nc,
>  	nc->encoded_va = encode_aligned_va(page_address(page), order,
>  					   page_is_pfmemalloc(page));
>  
> -	return page;
> +	/* Even if we own the page, we do not use atomic_set().
> +	 * This would break get_page_unless_zero() users.
> +	 */
> +	page_ref_add(page, PAGE_FRAG_CACHE_MAX_SIZE);
> +
> +	return true;
> +}
> +
> +/* Reload cache by reusing the old cache if it is possible, or
> + * refilling from the page allocator.
> + */
> +static bool __page_frag_cache_reload(struct page_frag_cache *nc,
> +				     gfp_t gfp_mask)
> +{
> +	if (likely(nc->encoded_va)) {
> +		if (__page_frag_cache_reuse(nc->encoded_va, nc->pagecnt_bias))
> +			goto out;
> +	}
> +
> +	if (unlikely(!__page_frag_cache_refill(nc, gfp_mask)))
> +		return false;
> +
> +out:
> +	/* reset page count bias and remaining to start of new frag */
> +	nc->pagecnt_bias = PAGE_FRAG_CACHE_MAX_SIZE + 1;
> +	nc->remaining = page_frag_cache_page_size(nc->encoded_va);

One thought I am having is that it might be better to have the
pagecnt_bias get set at the same time as the page_ref_add or the
set_page_count call. In addition setting the remaining value at the
same time probably would make sense as in the refill case you can make
use of the "order" value directly instead of having to write/read it
out of the encoded va/page.

With that we could simplify this function and get something closer to
what we had for the original alloc_va_align code.

> +	return true;
>  }
>  
>  void page_frag_cache_drain(struct page_frag_cache *nc)
> @@ -55,7 +100,7 @@ void page_frag_cache_drain(struct page_frag_cache *nc)
>  
>  	__page_frag_cache_drain(virt_to_head_page((void *)nc->encoded_va),
>  				nc->pagecnt_bias);
> -	nc->encoded_va = 0;
> +	memset(nc, 0, sizeof(*nc));
>  }
>  EXPORT_SYMBOL(page_frag_cache_drain);
>  
> @@ -73,67 +118,44 @@ void *__page_frag_alloc_va_align(struct page_frag_cache *nc,
>  				 unsigned int align_mask)
>  {
>  	unsigned long encoded_va = nc->encoded_va;
> -	unsigned int size, remaining;
> -	struct page *page;
> -
> -	if (unlikely(!encoded_va)) {

We should still be checking this before we even touch remaining.
Otherwise we greatly increase the risk of providing a bad virtual
address and have greatly decreased the likelihood of us catching
potential errors gracefully.

> -refill:
> -		page = __page_frag_cache_refill(nc, gfp_mask);
> -		if (!page)
> -			return NULL;
> -
> -		encoded_va = nc->encoded_va;
> -		size = page_frag_cache_page_size(encoded_va);
> -
> -		/* Even if we own the page, we do not use atomic_set().
> -		 * This would break get_page_unless_zero() users.
> -		 */
> -		page_ref_add(page, PAGE_FRAG_CACHE_MAX_SIZE);
> -
> -		/* reset page count bias and remaining to start of new frag */
> -		nc->pagecnt_bias = PAGE_FRAG_CACHE_MAX_SIZE + 1;
> -		nc->remaining = size;

With my suggested change above you could essentially just drop the
block starting from the comment and this function wouldn't need to
change as much as it is.

> -	} else {
> -		size = page_frag_cache_page_size(encoded_va);
> -	}
> +	unsigned int remaining;
>  
>  	remaining = nc->remaining & align_mask;
> -	if (unlikely(remaining < fragsz)) {
> -		if (unlikely(fragsz > PAGE_SIZE)) {
> -			/*
> -			 * The caller is trying to allocate a fragment
> -			 * with fragsz > PAGE_SIZE but the cache isn't big
> -			 * enough to satisfy the request, this may
> -			 * happen in low memory conditions.
> -			 * We don't release the cache page because
> -			 * it could make memory pressure worse
> -			 * so we simply return NULL here.
> -			 */
> -			return NULL;
> -		}
> -
> -		page = virt_to_page((void *)encoded_va);
>  
> -		if (!page_ref_sub_and_test(page, nc->pagecnt_bias))
> -			goto refill;
> -
> -		if (unlikely(encoded_page_pfmemalloc(encoded_va))) {
> -			free_unref_page(page, encoded_page_order(encoded_va));
> -			goto refill;
> -		}

Likewise for this block here. We can essentially just make use of the
__page_frag_cache_reuse function without the need to do a complete
rework of the code.

> +	/* As we have ensured remaining is zero when initializing and draining old
> +	 * cache, 'remaining >= fragsz' checking is enough to indicate there is
> +	 * enough available space for the new fragment allocation.
> +	 */
> +	if (likely(remaining >= fragsz)) {
> +		nc->pagecnt_bias--;
> +		nc->remaining = remaining - fragsz;
>  
> -		/* OK, page count is 0, we can safely set it */
> -		set_page_count(page, PAGE_FRAG_CACHE_MAX_SIZE + 1);
> +		return encoded_page_address(encoded_va) +
> +			(page_frag_cache_page_size(encoded_va) - remaining);
> +	}
>  
> -		/* reset page count bias and remaining to start of new frag */
> -		nc->pagecnt_bias = PAGE_FRAG_CACHE_MAX_SIZE + 1;
> -		remaining = size;
> +	if (unlikely(fragsz > PAGE_SIZE)) {
> +		/*
> +		 * The caller is trying to allocate a fragment with
> +		 * fragsz > PAGE_SIZE but the cache isn't big enough to satisfy
> +		 * the request, this may happen in low memory conditions. We don't
> +		 * release the cache page because it could make memory pressure
> +		 * worse so we simply return NULL here.
> +		 */
> +		return NULL;
>  	}
>  
> +	if (unlikely(!__page_frag_cache_reload(nc, gfp_mask)))
> +		return NULL;
> +
> +	/* As the we are allocating fragment from cache by count-up way, the offset
> +	 * of allocated fragment from the just reloaded cache is zero, so remaining
> +	 * aligning and offset calculation are not needed.
> +	 */
>  	nc->pagecnt_bias--;
> -	nc->remaining = remaining - fragsz;
> +	nc->remaining -= fragsz;
>  
> -	return encoded_page_address(encoded_va) + (size - remaining);
> +	return encoded_page_address(nc->encoded_va);
>  }
>  EXPORT_SYMBOL(__page_frag_alloc_va_align);
>  

Re: [PATCH net-next v13 08/14] mm: page_frag: some minor refactoring before adding new API

[Yunsheng Lin]

On 2024/8/15 1:54, Alexander H Duyck wrote:
> On Thu, 2024-08-08 at 20:37 +0800, Yunsheng Lin wrote:
>> Refactor common codes from __page_frag_alloc_va_align()
>> to __page_frag_cache_reload(), so that the new API can
>> make use of them.
>>
>> CC: Alexander Duyck <alexander.duyck@gmail.com>
>> Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
>> ---
>>  include/linux/page_frag_cache.h |   2 +-
>>  mm/page_frag_cache.c            | 138 ++++++++++++++++++--------------
>>  2 files changed, 81 insertions(+), 59 deletions(-)
>>
>> diff --git a/include/linux/page_frag_cache.h b/include/linux/page_frag_cache.h
>> index 4ce924eaf1b1..0abffdd10a1c 100644
>> --- a/include/linux/page_frag_cache.h
>> +++ b/include/linux/page_frag_cache.h
>> @@ -52,7 +52,7 @@ static inline void *encoded_page_address(unsigned long encoded_va)
>>  
>>  static inline void page_frag_cache_init(struct page_frag_cache *nc)
>>  {
>> -	nc->encoded_va = 0;
>> +	memset(nc, 0, sizeof(*nc));
>>  }
>>  
> 
> Still not a fan of this. Just setting encoded_va to 0 should be enough
> as the other fields will automatically be overwritten when the new page
> is allocated.
> 
> Relying on memset is problematic at best since you then introduce the
> potential for issues where remaining somehow gets corrupted but
> encoded_va/page is 0. I would rather have both of these being checked
> as a part of allocation than just just assuming it is valid if
> remaining is set.

Does adding something like VM_BUG_ON(!nc->encoded_va && nc->remaining) to
catch the above problem address your above concern?

> 
> I would prefer to keep the check for a non-0 encoded_page value and
> then check remaining rather than just rely on remaining as it creates a
> single point of failure. With that we can safely tear away a page and
> the next caller to try to allocate will populated a new page and the
> associated fields.

As mentioned before, the memset() is used mainly because of:
1. avoid a checking in the fast path.
2. avoid duplicating the checking pattern you mentioned above for the
   new API.

> 
>>  static inline bool page_frag_cache_is_pfmemalloc(struct page_frag_cache *nc)
>> diff --git a/mm/page_frag_cache.c b/mm/page_frag_cache.c
>> index 2544b292375a..4e6b1c4684f0 100644
>> --- a/mm/page_frag_cache.c
>> +++ b/mm/page_frag_cache.c
>> @@ -19,8 +19,27 @@
>>  #include <linux/page_frag_cache.h>
>>  #include "internal.h"
>>  

...

>> +
>> +/* Reload cache by reusing the old cache if it is possible, or
>> + * refilling from the page allocator.
>> + */
>> +static bool __page_frag_cache_reload(struct page_frag_cache *nc,
>> +				     gfp_t gfp_mask)
>> +{
>> +	if (likely(nc->encoded_va)) {
>> +		if (__page_frag_cache_reuse(nc->encoded_va, nc->pagecnt_bias))
>> +			goto out;
>> +	}
>> +
>> +	if (unlikely(!__page_frag_cache_refill(nc, gfp_mask)))
>> +		return false;
>> +
>> +out:
>> +	/* reset page count bias and remaining to start of new frag */
>> +	nc->pagecnt_bias = PAGE_FRAG_CACHE_MAX_SIZE + 1;
>> +	nc->remaining = page_frag_cache_page_size(nc->encoded_va);
> 
> One thought I am having is that it might be better to have the
> pagecnt_bias get set at the same time as the page_ref_add or the
> set_page_count call. In addition setting the remaining value at the
> same time probably would make sense as in the refill case you can make
> use of the "order" value directly instead of having to write/read it
> out of the encoded va/page.

Probably, there is always tradeoff to make regarding avoid code
duplication and avoid reading the order, I am not sure it matters
for both for case, I would rather keep the above pattern if there
is not obvious benefit for the other pattern.

> 
> With that we could simplify this function and get something closer to
> what we had for the original alloc_va_align code.
> 
>> +	return true;
>>  }
>>  
>>  void page_frag_cache_drain(struct page_frag_cache *nc)
>> @@ -55,7 +100,7 @@ void page_frag_cache_drain(struct page_frag_cache *nc)
>>  
>>  	__page_frag_cache_drain(virt_to_head_page((void *)nc->encoded_va),
>>  				nc->pagecnt_bias);
>> -	nc->encoded_va = 0;
>> +	memset(nc, 0, sizeof(*nc));
>>  }
>>  EXPORT_SYMBOL(page_frag_cache_drain);
>>  
>> @@ -73,67 +118,44 @@ void *__page_frag_alloc_va_align(struct page_frag_cache *nc,
>>  				 unsigned int align_mask)
>>  {
>>  	unsigned long encoded_va = nc->encoded_va;
>> -	unsigned int size, remaining;
>> -	struct page *page;
>> -
>> -	if (unlikely(!encoded_va)) {
> 
> We should still be checking this before we even touch remaining.
> Otherwise we greatly increase the risk of providing a bad virtual
> address and have greatly decreased the likelihood of us catching
> potential errors gracefully.
> 
>> -refill:
>> -		page = __page_frag_cache_refill(nc, gfp_mask);
>> -		if (!page)
>> -			return NULL;
>> -
>> -		encoded_va = nc->encoded_va;
>> -		size = page_frag_cache_page_size(encoded_va);
>> -
>> -		/* Even if we own the page, we do not use atomic_set().
>> -		 * This would break get_page_unless_zero() users.
>> -		 */
>> -		page_ref_add(page, PAGE_FRAG_CACHE_MAX_SIZE);
>> -
>> -		/* reset page count bias and remaining to start of new frag */
>> -		nc->pagecnt_bias = PAGE_FRAG_CACHE_MAX_SIZE + 1;
>> -		nc->remaining = size;
> 
> With my suggested change above you could essentially just drop the
> block starting from the comment and this function wouldn't need to
> change as much as it is.

It seems you are still suggesting that new API also duplicates the old
checking pattern in __page_frag_alloc_va_align()?

I would rather avoid the above if something like VM_BUG_ON() can address
your above concern.

Re: [PATCH net-next v13 08/14] mm: page_frag: some minor refactoring before adding new API

[Alexander Duyck]

On Wed, Aug 14, 2024 at 8:04 PM Yunsheng Lin <linyunsheng@huawei.com> wrote:
>
> On 2024/8/15 1:54, Alexander H Duyck wrote:
> > On Thu, 2024-08-08 at 20:37 +0800, Yunsheng Lin wrote:
> >> Refactor common codes from __page_frag_alloc_va_align()
> >> to __page_frag_cache_reload(), so that the new API can
> >> make use of them.
> >>
> >> CC: Alexander Duyck <alexander.duyck@gmail.com>
> >> Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
> >> ---
> >>  include/linux/page_frag_cache.h |   2 +-
> >>  mm/page_frag_cache.c            | 138 ++++++++++++++++++--------------
> >>  2 files changed, 81 insertions(+), 59 deletions(-)
> >>
> >> diff --git a/include/linux/page_frag_cache.h b/include/linux/page_frag_cache.h
> >> index 4ce924eaf1b1..0abffdd10a1c 100644
> >> --- a/include/linux/page_frag_cache.h
> >> +++ b/include/linux/page_frag_cache.h
> >> @@ -52,7 +52,7 @@ static inline void *encoded_page_address(unsigned long encoded_va)
> >>
> >>  static inline void page_frag_cache_init(struct page_frag_cache *nc)
> >>  {
> >> -    nc->encoded_va = 0;
> >> +    memset(nc, 0, sizeof(*nc));
> >>  }
> >>
> >
> > Still not a fan of this. Just setting encoded_va to 0 should be enough
> > as the other fields will automatically be overwritten when the new page
> > is allocated.
> >
> > Relying on memset is problematic at best since you then introduce the
> > potential for issues where remaining somehow gets corrupted but
> > encoded_va/page is 0. I would rather have both of these being checked
> > as a part of allocation than just just assuming it is valid if
> > remaining is set.
>
> Does adding something like VM_BUG_ON(!nc->encoded_va && nc->remaining) to
> catch the above problem address your above concern?

Not really. I would prefer to just retain the existing behavior.

> >
> > I would prefer to keep the check for a non-0 encoded_page value and
> > then check remaining rather than just rely on remaining as it creates a
> > single point of failure. With that we can safely tear away a page and
> > the next caller to try to allocate will populated a new page and the
> > associated fields.
>
> As mentioned before, the memset() is used mainly because of:
> 1. avoid a checking in the fast path.
> 2. avoid duplicating the checking pattern you mentioned above for the
>    new API.

I'm not a fan of the new code flow after getting rid of the checking
in the fast path. The code is becoming a tangled mess of spaghetti
code in my opinion. Arguably the patches don't help as you are taking
huge steps in many of these patches and it is making it hard to read.
In addition the code becomes more obfuscated with each patch which is
one of the reasons why I would have preferred to see this set broken
into a couple sets so we can give it some time for any of the kinks to
get worked out.

> >
> >>  static inline bool page_frag_cache_is_pfmemalloc(struct page_frag_cache *nc)
> >> diff --git a/mm/page_frag_cache.c b/mm/page_frag_cache.c
> >> index 2544b292375a..4e6b1c4684f0 100644
> >> --- a/mm/page_frag_cache.c
> >> +++ b/mm/page_frag_cache.c
> >> @@ -19,8 +19,27 @@
> >>  #include <linux/page_frag_cache.h>
> >>  #include "internal.h"
> >>
>
> ...
>
> >> +
> >> +/* Reload cache by reusing the old cache if it is possible, or
> >> + * refilling from the page allocator.
> >> + */
> >> +static bool __page_frag_cache_reload(struct page_frag_cache *nc,
> >> +                                 gfp_t gfp_mask)
> >> +{
> >> +    if (likely(nc->encoded_va)) {
> >> +            if (__page_frag_cache_reuse(nc->encoded_va, nc->pagecnt_bias))
> >> +                    goto out;
> >> +    }
> >> +
> >> +    if (unlikely(!__page_frag_cache_refill(nc, gfp_mask)))
> >> +            return false;
> >> +
> >> +out:
> >> +    /* reset page count bias and remaining to start of new frag */
> >> +    nc->pagecnt_bias = PAGE_FRAG_CACHE_MAX_SIZE + 1;
> >> +    nc->remaining = page_frag_cache_page_size(nc->encoded_va);
> >
> > One thought I am having is that it might be better to have the
> > pagecnt_bias get set at the same time as the page_ref_add or the
> > set_page_count call. In addition setting the remaining value at the
> > same time probably would make sense as in the refill case you can make
> > use of the "order" value directly instead of having to write/read it
> > out of the encoded va/page.
>
> Probably, there is always tradeoff to make regarding avoid code
> duplication and avoid reading the order, I am not sure it matters
> for both for case, I would rather keep the above pattern if there
> is not obvious benefit for the other pattern.

Part of it is more about keeping the functions contained to generating
self contained objects. I am not a fan of us splitting up the page
init into a few sections as it makes it much easier to mess up a page
by changing one spot and overlooking the fact that an additional page
is needed somewhere else.

> >
> > With that we could simplify this function and get something closer to
> > what we had for the original alloc_va_align code.
> >
> >> +    return true;
> >>  }
> >>
> >>  void page_frag_cache_drain(struct page_frag_cache *nc)
> >> @@ -55,7 +100,7 @@ void page_frag_cache_drain(struct page_frag_cache *nc)
> >>
> >>      __page_frag_cache_drain(virt_to_head_page((void *)nc->encoded_va),
> >>                              nc->pagecnt_bias);
> >> -    nc->encoded_va = 0;
> >> +    memset(nc, 0, sizeof(*nc));
> >>  }
> >>  EXPORT_SYMBOL(page_frag_cache_drain);
> >>
> >> @@ -73,67 +118,44 @@ void *__page_frag_alloc_va_align(struct page_frag_cache *nc,
> >>                               unsigned int align_mask)
> >>  {
> >>      unsigned long encoded_va = nc->encoded_va;
> >> -    unsigned int size, remaining;
> >> -    struct page *page;
> >> -
> >> -    if (unlikely(!encoded_va)) {
> >
> > We should still be checking this before we even touch remaining.
> > Otherwise we greatly increase the risk of providing a bad virtual
> > address and have greatly decreased the likelihood of us catching
> > potential errors gracefully.
> >
> >> -refill:
> >> -            page = __page_frag_cache_refill(nc, gfp_mask);
> >> -            if (!page)
> >> -                    return NULL;
> >> -
> >> -            encoded_va = nc->encoded_va;
> >> -            size = page_frag_cache_page_size(encoded_va);
> >> -
> >> -            /* Even if we own the page, we do not use atomic_set().
> >> -             * This would break get_page_unless_zero() users.
> >> -             */
> >> -            page_ref_add(page, PAGE_FRAG_CACHE_MAX_SIZE);
> >> -
> >> -            /* reset page count bias and remaining to start of new frag */
> >> -            nc->pagecnt_bias = PAGE_FRAG_CACHE_MAX_SIZE + 1;
> >> -            nc->remaining = size;
> >
> > With my suggested change above you could essentially just drop the
> > block starting from the comment and this function wouldn't need to
> > change as much as it is.
>
> It seems you are still suggesting that new API also duplicates the old
> checking pattern in __page_frag_alloc_va_align()?
>
> I would rather avoid the above if something like VM_BUG_ON() can address
> your above concern.

Yes, that is what I am suggesting. It makes the code much less prone
to any sort of possible races as resetting encoded_va would make it so
that reads for all the other fields would be skipped versus having to
use a memset which differs in implementation depending on the
architecture.

Re: [PATCH net-next v13 08/14] mm: page_frag: some minor refactoring before adding new API

[Yunsheng Lin]

On 2024/8/15 23:09, Alexander Duyck wrote:
> On Wed, Aug 14, 2024 at 8:04 PM Yunsheng Lin <linyunsheng@huawei.com> wrote:
>>
>> On 2024/8/15 1:54, Alexander H Duyck wrote:
>>> On Thu, 2024-08-08 at 20:37 +0800, Yunsheng Lin wrote:
>>>> Refactor common codes from __page_frag_alloc_va_align()
>>>> to __page_frag_cache_reload(), so that the new API can
>>>> make use of them.
>>>>
>>>> CC: Alexander Duyck <alexander.duyck@gmail.com>
>>>> Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
>>>> ---
>>>>  include/linux/page_frag_cache.h |   2 +-
>>>>  mm/page_frag_cache.c            | 138 ++++++++++++++++++--------------
>>>>  2 files changed, 81 insertions(+), 59 deletions(-)
>>>>
>>>> diff --git a/include/linux/page_frag_cache.h b/include/linux/page_frag_cache.h
>>>> index 4ce924eaf1b1..0abffdd10a1c 100644
>>>> --- a/include/linux/page_frag_cache.h
>>>> +++ b/include/linux/page_frag_cache.h
>>>> @@ -52,7 +52,7 @@ static inline void *encoded_page_address(unsigned long encoded_va)
>>>>
>>>>  static inline void page_frag_cache_init(struct page_frag_cache *nc)
>>>>  {
>>>> -    nc->encoded_va = 0;
>>>> +    memset(nc, 0, sizeof(*nc));
>>>>  }
>>>>
>>>
>>> Still not a fan of this. Just setting encoded_va to 0 should be enough
>>> as the other fields will automatically be overwritten when the new page
>>> is allocated.
>>>
>>> Relying on memset is problematic at best since you then introduce the
>>> potential for issues where remaining somehow gets corrupted but
>>> encoded_va/page is 0. I would rather have both of these being checked
>>> as a part of allocation than just just assuming it is valid if
>>> remaining is set.
>>
>> Does adding something like VM_BUG_ON(!nc->encoded_va && nc->remaining) to
>> catch the above problem address your above concern?
> 
> Not really. I would prefer to just retain the existing behavior.
As my understanding, it is a implementation detail that API caller does
not need to care about if the API is used correctly. If not, we have bigger
problem than above.

If there is a error in that implementation, it would be good to point it
out. And there is already a comment explaining that implementation detail
in this patch, doesn't adding a explicit VM_BUG_ON() make it more obvious.

> 
>>>
>>> I would prefer to keep the check for a non-0 encoded_page value and
>>> then check remaining rather than just rely on remaining as it creates a
>>> single point of failure. With that we can safely tear away a page and
>>> the next caller to try to allocate will populated a new page and the
>>> associated fields.
>>
>> As mentioned before, the memset() is used mainly because of:
>> 1. avoid a checking in the fast path.
>> 2. avoid duplicating the checking pattern you mentioned above for the
>>    new API.
> 
> I'm not a fan of the new code flow after getting rid of the checking
> in the fast path. The code is becoming a tangled mess of spaghetti

I am not sure if you get the point that getting rid of nc->encoded_va
checking in the fast path is the reason we are able able to refactor
common codes into __page_frag_cache_reload(), so that both the old API
and new APIs can reuse the common codes.

> code in my opinion. Arguably the patches don't help as you are taking
> huge steps in many of these patches and it is making it hard to read.
> In addition the code becomes more obfuscated with each patch which is
> one of the reasons why I would have preferred to see this set broken
> into a couple sets so we can give it some time for any of the kinks to
> get worked out.

If there is no new APIs added, I guess I am agreed with your above
argument.
With the new API for new use case, the refactoring in this patch make
code more reusable and maintainable, that is why I would have preferred
not to break this patchset into more patchsets as it is already hard to
argue the reason behind the refactoring.

> 
>>>
>>>>  static inline bool page_frag_cache_is_pfmemalloc(struct page_frag_cache *nc)
>>>> diff --git a/mm/page_frag_cache.c b/mm/page_frag_cache.c
>>>> index 2544b292375a..4e6b1c4684f0 100644
>>>> --- a/mm/page_frag_cache.c
>>>> +++ b/mm/page_frag_cache.c
>>>> @@ -19,8 +19,27 @@
>>>>  #include <linux/page_frag_cache.h>
>>>>  #include "internal.h"
>>>>
>>
>> ...
>>
>>>> +
>>>> +/* Reload cache by reusing the old cache if it is possible, or
>>>> + * refilling from the page allocator.
>>>> + */
>>>> +static bool __page_frag_cache_reload(struct page_frag_cache *nc,
>>>> +                                 gfp_t gfp_mask)
>>>> +{
>>>> +    if (likely(nc->encoded_va)) {
>>>> +            if (__page_frag_cache_reuse(nc->encoded_va, nc->pagecnt_bias))
>>>> +                    goto out;
>>>> +    }
>>>> +
>>>> +    if (unlikely(!__page_frag_cache_refill(nc, gfp_mask)))
>>>> +            return false;
>>>> +
>>>> +out:
>>>> +    /* reset page count bias and remaining to start of new frag */
>>>> +    nc->pagecnt_bias = PAGE_FRAG_CACHE_MAX_SIZE + 1;
>>>> +    nc->remaining = page_frag_cache_page_size(nc->encoded_va);
>>>
>>> One thought I am having is that it might be better to have the
>>> pagecnt_bias get set at the same time as the page_ref_add or the
>>> set_page_count call. In addition setting the remaining value at the
>>> same time probably would make sense as in the refill case you can make
>>> use of the "order" value directly instead of having to write/read it
>>> out of the encoded va/page.
>>
>> Probably, there is always tradeoff to make regarding avoid code
>> duplication and avoid reading the order, I am not sure it matters
>> for both for case, I would rather keep the above pattern if there
>> is not obvious benefit for the other pattern.
> 
> Part of it is more about keeping the functions contained to generating
> self contained objects. I am not a fan of us splitting up the page
> init into a few sections as it makes it much easier to mess up a page
> by changing one spot and overlooking the fact that an additional page
> is needed somewhere else.

To be honest, I am not so obsessed with where are pagecnt_bias and
remaining set.
I am obsessed with whether the __page_frag_cache_reload() is needed.
Let's be more specific about your suggestion here: are you suggesting to
remove __page_frag_cache_reload()?
If yes, are you really expecting both old and new API duplicating the
below checking pattern? Why?

if (likely(nc->encoded_va)) {
	if (__page_frag_cache_reuse(nc->encoded_va, nc->pagecnt_bias))
		...
}

if (unlikely(remaining < fragsz)) {
	page = __page_frag_cache_refill(nc, gfp_mask);
	....
}

If no, doesn't it make sense to call __page_frag_cache_reload() for both
old and new API?

> 
>>>
>>> With that we could simplify this function and get something closer to
>>> what we had for the original alloc_va_align code.
>>>
>>>> +    return true;
>>>>  }
>>>>
>>>>  void page_frag_cache_drain(struct page_frag_cache *nc)
>>>> @@ -55,7 +100,7 @@ void page_frag_cache_drain(struct page_frag_cache *nc)
>>>>
>>>>      __page_frag_cache_drain(virt_to_head_page((void *)nc->encoded_va),
>>>>                              nc->pagecnt_bias);
>>>> -    nc->encoded_va = 0;
>>>> +    memset(nc, 0, sizeof(*nc));
>>>>  }
>>>>  EXPORT_SYMBOL(page_frag_cache_drain);
>>>>
>>>> @@ -73,67 +118,44 @@ void *__page_frag_alloc_va_align(struct page_frag_cache *nc,
>>>>                               unsigned int align_mask)
>>>>  {
>>>>      unsigned long encoded_va = nc->encoded_va;
>>>> -    unsigned int size, remaining;
>>>> -    struct page *page;
>>>> -
>>>> -    if (unlikely(!encoded_va)) {
>>>
>>> We should still be checking this before we even touch remaining.
>>> Otherwise we greatly increase the risk of providing a bad virtual
>>> address and have greatly decreased the likelihood of us catching
>>> potential errors gracefully.

I would argue that by duplicating the above checking for both the old
and new API will make the code less maintainable, for example, when
fixing bug or making changing to the duplicated checking, it is more
likely miss to change some of them if there are duplicated checking
codes.

>>>
>>>> -refill:
>>>> -            page = __page_frag_cache_refill(nc, gfp_mask);
>>>> -            if (!page)
>>>> -                    return NULL;
>>>> -
>>>> -            encoded_va = nc->encoded_va;
>>>> -            size = page_frag_cache_page_size(encoded_va);
>>>> -
>>>> -            /* Even if we own the page, we do not use atomic_set().
>>>> -             * This would break get_page_unless_zero() users.
>>>> -             */
>>>> -            page_ref_add(page, PAGE_FRAG_CACHE_MAX_SIZE);
>>>> -
>>>> -            /* reset page count bias and remaining to start of new frag */
>>>> -            nc->pagecnt_bias = PAGE_FRAG_CACHE_MAX_SIZE + 1;
>>>> -            nc->remaining = size;
>>>
>>> With my suggested change above you could essentially just drop the
>>> block starting from the comment and this function wouldn't need to
>>> change as much as it is.
>>
>> It seems you are still suggesting that new API also duplicates the old
>> checking pattern in __page_frag_alloc_va_align()?
>>
>> I would rather avoid the above if something like VM_BUG_ON() can address
>> your above concern.
> 
> Yes, that is what I am suggesting. It makes the code much less prone
> to any sort of possible races as resetting encoded_va would make it so
> that reads for all the other fields would be skipped versus having to
> use a memset which differs in implementation depending on the
> architecture.

It would good to be more specific about what is the race here? if it does
exist, we can fix it.

And it would be good to have more specific suggestion and argument too,
othewise it just you arguing for preserving old behavior to make
the code much less prone to any sort of possible races, and me arguing
for making the old code more reusable and maintainable for the new API.

Re: [PATCH net-next v13 11/14] mm: page_frag: introduce prepare/probe/commit API

[Alexander H Duyck]

On Thu, 2024-08-08 at 20:37 +0800, Yunsheng Lin wrote:
> There are many use cases that need minimum memory in order
> for forward progress, but more performant if more memory is
> available or need to probe the cache info to use any memory
> available for frag caoleasing reason.
> 
> Currently skb_page_frag_refill() API is used to solve the
> above use cases, but caller needs to know about the internal
> detail and access the data field of 'struct page_frag' to
> meet the requirement of the above use cases and its
> implementation is similar to the one in mm subsystem.
> 
> To unify those two page_frag implementations, introduce a
> prepare API to ensure minimum memory is satisfied and return
> how much the actual memory is available to the caller and a
> probe API to report the current available memory to caller
> without doing cache refilling. The caller needs to either call
> the commit API to report how much memory it actually uses, or
> not do so if deciding to not use any memory.
> 
> CC: Alexander Duyck <alexander.duyck@gmail.com>
> Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
> ---
>  include/linux/page_frag_cache.h |  75 ++++++++++++++++
>  mm/page_frag_cache.c            | 152 ++++++++++++++++++++++++++++----
>  2 files changed, 212 insertions(+), 15 deletions(-)
> 
> diff --git a/include/linux/page_frag_cache.h b/include/linux/page_frag_cache.h
> index 0abffdd10a1c..ba5d7f8a03cd 100644
> --- a/include/linux/page_frag_cache.h
> +++ b/include/linux/page_frag_cache.h
> @@ -7,6 +7,8 @@
>  #include <linux/build_bug.h>
>  #include <linux/log2.h>
>  #include <linux/types.h>
> +#include <linux/mm.h>
> +#include <linux/mmdebug.h>
>  #include <linux/mm_types_task.h>
>  
>  #if (PAGE_SIZE < PAGE_FRAG_CACHE_MAX_SIZE)
> @@ -67,6 +69,9 @@ static inline unsigned int page_frag_cache_page_size(unsigned long encoded_va)
>  
>  void page_frag_cache_drain(struct page_frag_cache *nc);
>  void __page_frag_cache_drain(struct page *page, unsigned int count);
> +struct page *page_frag_alloc_pg(struct page_frag_cache *nc,
> +				unsigned int *offset, unsigned int fragsz,
> +				gfp_t gfp);
>  void *__page_frag_alloc_va_align(struct page_frag_cache *nc,
>  				 unsigned int fragsz, gfp_t gfp_mask,
>  				 unsigned int align_mask);
> @@ -79,12 +84,82 @@ static inline void *page_frag_alloc_va_align(struct page_frag_cache *nc,
>  	return __page_frag_alloc_va_align(nc, fragsz, gfp_mask, -align);
>  }
>  
> +static inline unsigned int page_frag_cache_page_offset(const struct page_frag_cache *nc)
> +{
> +	return page_frag_cache_page_size(nc->encoded_va) - nc->remaining;
> +}
> +
>  static inline void *page_frag_alloc_va(struct page_frag_cache *nc,
>  				       unsigned int fragsz, gfp_t gfp_mask)
>  {
>  	return __page_frag_alloc_va_align(nc, fragsz, gfp_mask, ~0u);
>  }
>  
> +void *page_frag_alloc_va_prepare(struct page_frag_cache *nc, unsigned int *fragsz,
> +				 gfp_t gfp);
> +
> +static inline void *page_frag_alloc_va_prepare_align(struct page_frag_cache *nc,
> +						     unsigned int *fragsz,
> +						     gfp_t gfp,
> +						     unsigned int align)
> +{
> +	WARN_ON_ONCE(!is_power_of_2(align) || align > PAGE_SIZE);
> +	nc->remaining = nc->remaining & -align;
> +	return page_frag_alloc_va_prepare(nc, fragsz, gfp);
> +}
> +
> +struct page *page_frag_alloc_pg_prepare(struct page_frag_cache *nc,
> +					unsigned int *offset,
> +					unsigned int *fragsz, gfp_t gfp);
> +
> +struct page *page_frag_alloc_prepare(struct page_frag_cache *nc,
> +				     unsigned int *offset,
> +				     unsigned int *fragsz,
> +				     void **va, gfp_t gfp);
> +
> +static inline struct page *page_frag_alloc_probe(struct page_frag_cache *nc,
> +						 unsigned int *offset,
> +						 unsigned int *fragsz,
> +						 void **va)
> +{
> +	unsigned long encoded_va = nc->encoded_va;
> +	struct page *page;
> +
> +	VM_BUG_ON(!*fragsz);
> +	if (unlikely(nc->remaining < *fragsz))
> +		return NULL;
> +
> +	*va = encoded_page_address(encoded_va);
> +	page = virt_to_page(*va);
> +	*fragsz = nc->remaining;
> +	*offset = page_frag_cache_page_size(encoded_va) - *fragsz;
> +	*va += *offset;
> +
> +	return page;
> +}
> +

I still think this should be populating a bio_vec instead of passing
multiple arguments by pointer. With that you would be able to get all
the fields without as many arguments having to be passed.

> +static inline void page_frag_alloc_commit(struct page_frag_cache *nc,
> +					  unsigned int fragsz)
> +{
> +	VM_BUG_ON(fragsz > nc->remaining || !nc->pagecnt_bias);
> +	nc->pagecnt_bias--;
> +	nc->remaining -= fragsz;
> +}
> +

I would really like to see this accept a bio_vec as well. With that you
could verify the page and offset matches the expected value before
applying fragsz.

> +static inline void page_frag_alloc_commit_noref(struct page_frag_cache *nc,
> +						unsigned int fragsz)
> +{
> +	VM_BUG_ON(fragsz > nc->remaining);
> +	nc->remaining -= fragsz;
> +}
> +

Same here.

> +static inline void page_frag_alloc_abort(struct page_frag_cache *nc,
> +					 unsigned int fragsz)
> +{
> +	nc->pagecnt_bias++;
> +	nc->remaining += fragsz;
> +}
> +

This doesn't add up. Why would you need abort if you have commit? Isn't
this more of a revert? I wouldn't think that would be valid as it is
possible you took some sort of action that might have resulted in this
memory already being shared. We shouldn't allow rewinding the offset
pointer without knowing that there are no other entities sharing the
page.

>  void page_frag_free_va(void *addr);
>  
>  #endif
> diff --git a/mm/page_frag_cache.c b/mm/page_frag_cache.c
> index 27596b84b452..f8fad7d2cca8 100644
> --- a/mm/page_frag_cache.c
> +++ b/mm/page_frag_cache.c
> @@ -19,27 +19,27 @@
>  #include <linux/page_frag_cache.h>
>  #include "internal.h"
>  
> -static bool __page_frag_cache_reuse(unsigned long encoded_va,
> -				    unsigned int pagecnt_bias)
> +static struct page *__page_frag_cache_reuse(unsigned long encoded_va,
> +					    unsigned int pagecnt_bias)
>  {
>  	struct page *page;
>  
>  	page = virt_to_page((void *)encoded_va);
>  	if (!page_ref_sub_and_test(page, pagecnt_bias))
> -		return false;
> +		return NULL;
>  
>  	if (unlikely(encoded_page_pfmemalloc(encoded_va))) {
>  		free_unref_page(page, encoded_page_order(encoded_va));
> -		return false;
> +		return NULL;
>  	}
>  
>  	/* OK, page count is 0, we can safely set it */
>  	set_page_count(page, PAGE_FRAG_CACHE_MAX_SIZE + 1);
> -	return true;
> +	return page;
>  }
>  
> -static bool __page_frag_cache_refill(struct page_frag_cache *nc,
> -				     gfp_t gfp_mask)
> +static struct page *__page_frag_cache_refill(struct page_frag_cache *nc,
> +					     gfp_t gfp_mask)
>  {
>  	unsigned long order = PAGE_FRAG_CACHE_MAX_ORDER;
>  	struct page *page = NULL;
> @@ -55,7 +55,7 @@ static bool __page_frag_cache_refill(struct page_frag_cache *nc,
>  		page = __alloc_pages(gfp, 0, numa_mem_id(), NULL);
>  		if (unlikely(!page)) {
>  			memset(nc, 0, sizeof(*nc));
> -			return false;
> +			return NULL;
>  		}
>  
>  		order = 0;
> @@ -69,29 +69,151 @@ static bool __page_frag_cache_refill(struct page_frag_cache *nc,
>  	 */
>  	page_ref_add(page, PAGE_FRAG_CACHE_MAX_SIZE);
>  
> -	return true;
> +	return page;
>  }
>  
>  /* Reload cache by reusing the old cache if it is possible, or
>   * refilling from the page allocator.
>   */
> -static bool __page_frag_cache_reload(struct page_frag_cache *nc,
> -				     gfp_t gfp_mask)
> +static struct page *__page_frag_cache_reload(struct page_frag_cache *nc,
> +					     gfp_t gfp_mask)
>  {
> +	struct page *page;
> +
>  	if (likely(nc->encoded_va)) {
> -		if (__page_frag_cache_reuse(nc->encoded_va, nc->pagecnt_bias))
> +		page = __page_frag_cache_reuse(nc->encoded_va, nc->pagecnt_bias);
> +		if (page)
>  			goto out;
>  	}
>  
> -	if (unlikely(!__page_frag_cache_refill(nc, gfp_mask)))
> -		return false;
> +	page = __page_frag_cache_refill(nc, gfp_mask);
> +	if (unlikely(!page))
> +		return NULL;
>  
>  out:
>  	/* reset page count bias and remaining to start of new frag */
>  	nc->pagecnt_bias = PAGE_FRAG_CACHE_MAX_SIZE + 1;
>  	nc->remaining = page_frag_cache_page_size(nc->encoded_va);
> -	return true;
> +	return page;
> +}
> +

None of the functions above need to be returning page.

> +void *page_frag_alloc_va_prepare(struct page_frag_cache *nc,
> +				 unsigned int *fragsz, gfp_t gfp)
> +{
> +	unsigned int remaining = nc->remaining;
> +
> +	VM_BUG_ON(!*fragsz);
> +	if (likely(remaining >= *fragsz)) {
> +		unsigned long encoded_va = nc->encoded_va;
> +
> +		*fragsz = remaining;
> +
> +		return encoded_page_address(encoded_va) +
> +			(page_frag_cache_page_size(encoded_va) - remaining);
> +	}
> +
> +	if (unlikely(*fragsz > PAGE_SIZE))
> +		return NULL;
> +
> +	/* When reload fails, nc->encoded_va and nc->remaining are both reset
> +	 * to zero, so there is no need to check the return value here.
> +	 */
> +	__page_frag_cache_reload(nc, gfp);
> +
> +	*fragsz = nc->remaining;
> +	return encoded_page_address(nc->encoded_va);
> +}
> +EXPORT_SYMBOL(page_frag_alloc_va_prepare);
> +
> +struct page *page_frag_alloc_pg_prepare(struct page_frag_cache *nc,
> +					unsigned int *offset,
> +					unsigned int *fragsz, gfp_t gfp)
> +{
> +	unsigned int remaining = nc->remaining;
> +	struct page *page;
> +
> +	VM_BUG_ON(!*fragsz);
> +	if (likely(remaining >= *fragsz)) {
> +		unsigned long encoded_va = nc->encoded_va;
> +
> +		*offset = page_frag_cache_page_size(encoded_va) - remaining;
> +		*fragsz = remaining;
> +
> +		return virt_to_page((void *)encoded_va);
> +	}
> +
> +	if (unlikely(*fragsz > PAGE_SIZE))
> +		return NULL;
> +
> +	page = __page_frag_cache_reload(nc, gfp);
> +	*offset = 0;
> +	*fragsz = nc->remaining;
> +	return page;
> +}
> +EXPORT_SYMBOL(page_frag_alloc_pg_prepare);
> +
> +struct page *page_frag_alloc_prepare(struct page_frag_cache *nc,
> +				     unsigned int *offset,
> +				     unsigned int *fragsz,
> +				     void **va, gfp_t gfp)
> +{
> +	unsigned int remaining = nc->remaining;
> +	struct page *page;
> +
> +	VM_BUG_ON(!*fragsz);
> +	if (likely(remaining >= *fragsz)) {
> +		unsigned long encoded_va = nc->encoded_va;
> +
> +		*offset = page_frag_cache_page_size(encoded_va) - remaining;
> +		*va = encoded_page_address(encoded_va) + *offset;
> +		*fragsz = remaining;
> +
> +		return virt_to_page((void *)encoded_va);
> +	}
> +
> +	if (unlikely(*fragsz > PAGE_SIZE))
> +		return NULL;
> +
> +	page = __page_frag_cache_reload(nc, gfp);
> +	*offset = 0;
> +	*fragsz = nc->remaining;
> +	*va = encoded_page_address(nc->encoded_va);
> +
> +	return page;
> +}
> +EXPORT_SYMBOL(page_frag_alloc_prepare);
> +
> +struct page *page_frag_alloc_pg(struct page_frag_cache *nc,
> +				unsigned int *offset, unsigned int fragsz,
> +				gfp_t gfp)
> +{
> +	unsigned int remaining = nc->remaining;
> +	struct page *page;
> +
> +	VM_BUG_ON(!fragsz);
> +	if (likely(remaining >= fragsz)) {
> +		unsigned long encoded_va = nc->encoded_va;
> +
> +		*offset = page_frag_cache_page_size(encoded_va) -
> +				remaining;
> +
> +		return virt_to_page((void *)encoded_va);
> +	}
> +
> +	if (unlikely(fragsz > PAGE_SIZE))
> +		return NULL;
> +
> +	page = __page_frag_cache_reload(nc, gfp);
> +	if (unlikely(!page))
> +		return NULL;
> +
> +	*offset = 0;
> +	nc->remaining = remaining - fragsz;
> +	nc->pagecnt_bias--;
> +
> +	return page;
>  }
> +EXPORT_SYMBOL(page_frag_alloc_pg);

Again, this isn't returning a page. It is essentially returning a
bio_vec without calling it as such. You might as well pass the bio_vec
pointer as an argument and just have it populate it directly.

It would be identical to the existing page_frag for all intents and
purposes. In addition you could use that as an intermediate value
between the page_frag_cache for your prepare/commit call setup as you
could limit the size/bv_len to being the only item that can be
adjusted, specifically reduced between the prepare and commit calls.

Re: [PATCH net-next v13 11/14] mm: page_frag: introduce prepare/probe/commit API

[Yunsheng Lin]

On 2024/8/15 5:00, Alexander H Duyck wrote:

...

>
>> +static inline struct page *page_frag_alloc_probe(struct page_frag_cache *nc,
>> +						 unsigned int *offset,
>> +						 unsigned int *fragsz,
>> +						 void **va)
>> +{
>> +	unsigned long encoded_va = nc->encoded_va;
>> +	struct page *page;
>> +
>> +	VM_BUG_ON(!*fragsz);
>> +	if (unlikely(nc->remaining < *fragsz))
>> +		return NULL;
>> +
>> +	*va = encoded_page_address(encoded_va);
>> +	page = virt_to_page(*va);
>> +	*fragsz = nc->remaining;
>> +	*offset = page_frag_cache_page_size(encoded_va) - *fragsz;
>> +	*va += *offset;
>> +
>> +	return page;
>> +}
>> +
> 
> I still think this should be populating a bio_vec instead of passing
> multiple arguments by pointer. With that you would be able to get all
> the fields without as many arguments having to be passed.

As I was already arguing in [1]:
If most of the page_frag API callers doesn't access 'struct bio_vec'
directly and use something like bvec_iter_* API to do the accessing,
then I am agreed with the above argument.

But right now, most of the page_frag API callers are accessing 'va'
directly to do the memcpy'ing, and accessing 'page & off & len' directly
to do skb frag filling, so I am not really sure what's the point of
indirection using the 'struct bio_vec' here.

And adding 'struct bio_vec' for page_frag and accessing the value of it
directly may be against of the design choice of 'struct bio_vec', as
there seems to be no inline helper defined to access the value of
'struct bio_vec' directly in bvec.h

1. https://lore.kernel.org/all/ca6be29e-ab53-4673-9624-90d41616a154@huawei.com/

> 
>> +static inline void page_frag_alloc_commit(struct page_frag_cache *nc,
>> +					  unsigned int fragsz)
>> +{
>> +	VM_BUG_ON(fragsz > nc->remaining || !nc->pagecnt_bias);
>> +	nc->pagecnt_bias--;
>> +	nc->remaining -= fragsz;
>> +}
>> +
> 

> 
>> +static inline void page_frag_alloc_abort(struct page_frag_cache *nc,
>> +					 unsigned int fragsz)
>> +{
>> +	nc->pagecnt_bias++;
>> +	nc->remaining += fragsz;
>> +}
>> +
> 
> This doesn't add up. Why would you need abort if you have commit? Isn't
> this more of a revert? I wouldn't think that would be valid as it is
> possible you took some sort of action that might have resulted in this
> memory already being shared. We shouldn't allow rewinding the offset
> pointer without knowing that there are no other entities sharing the
> page.

This is used for __tun_build_skb() in drivers/net/tun.c as below, mainly
used to avoid performance penalty for XDP drop case:

--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -1598,21 +1598,19 @@ static bool tun_can_build_skb(struct tun_struct *tun, struct tun_file *tfile,
 }

 static struct sk_buff *__tun_build_skb(struct tun_file *tfile,
-				       struct page_frag *alloc_frag, char *buf,
-				       int buflen, int len, int pad)
+				       char *buf, int buflen, int len, int pad)
 {
 	struct sk_buff *skb = build_skb(buf, buflen);

-	if (!skb)
+	if (!skb) {
+		page_frag_free_va(buf);
 		return ERR_PTR(-ENOMEM);
+	}

 	skb_reserve(skb, pad);
 	skb_put(skb, len);
 	skb_set_owner_w(skb, tfile->socket.sk);

-	get_page(alloc_frag->page);
-	alloc_frag->offset += buflen;
-
 	return skb;
 }

@@ -1660,7 +1658,7 @@ static struct sk_buff *tun_build_skb(struct tun_struct *tun,
 				     struct virtio_net_hdr *hdr,
 				     int len, int *skb_xdp)
 {
-	struct page_frag *alloc_frag = &current->task_frag;
+	struct page_frag_cache *alloc_frag = &current->task_frag;
 	struct bpf_net_context __bpf_net_ctx, *bpf_net_ctx;
 	struct bpf_prog *xdp_prog;
 	int buflen = SKB_DATA_ALIGN(sizeof(struct skb_shared_info));
@@ -1676,16 +1674,16 @@ static struct sk_buff *tun_build_skb(struct tun_struct *tun,
 	buflen += SKB_DATA_ALIGN(len + pad);
 	rcu_read_unlock();

-	alloc_frag->offset = ALIGN((u64)alloc_frag->offset, SMP_CACHE_BYTES);
-	if (unlikely(!skb_page_frag_refill(buflen, alloc_frag, GFP_KERNEL)))
+	buf = page_frag_alloc_va_align(alloc_frag, buflen, GFP_KERNEL,
+				       SMP_CACHE_BYTES);
+	if (unlikely(!buf))
 		return ERR_PTR(-ENOMEM);

-	buf = (char *)page_address(alloc_frag->page) + alloc_frag->offset;
-	copied = copy_page_from_iter(alloc_frag->page,
-				     alloc_frag->offset + pad,
-				     len, from);
-	if (copied != len)
+	copied = copy_from_iter(buf + pad, len, from);
+	if (copied != len) {
+		page_frag_alloc_abort(alloc_frag, buflen);
 		return ERR_PTR(-EFAULT);
+	}

 	/* There's a small window that XDP may be set after the check
 	 * of xdp_prog above, this should be rare and for simplicity
@@ -1693,8 +1691,7 @@ static struct sk_buff *tun_build_skb(struct tun_struct *tun,
 	 */
 	if (hdr->gso_type || !xdp_prog) {
 		*skb_xdp = 1;
-		return __tun_build_skb(tfile, alloc_frag, buf, buflen, len,
-				       pad);
+		return __tun_build_skb(tfile, buf, buflen, len, pad);
 	}

 	*skb_xdp = 0;
@@ -1711,21 +1708,16 @@ static struct sk_buff *tun_build_skb(struct tun_struct *tun,
 		xdp_prepare_buff(&xdp, buf, pad, len, false);

 		act = bpf_prog_run_xdp(xdp_prog, &xdp);
-		if (act == XDP_REDIRECT || act == XDP_TX) {
-			get_page(alloc_frag->page);
-			alloc_frag->offset += buflen;
-		}
 		err = tun_xdp_act(tun, xdp_prog, &xdp, act);
-		if (err < 0) {
-			if (act == XDP_REDIRECT || act == XDP_TX)
-				put_page(alloc_frag->page);
-			goto out;
-		}
-
 		if (err == XDP_REDIRECT)
 			xdp_do_flush();
-		if (err != XDP_PASS)
+
+		if (err == XDP_REDIRECT || err == XDP_TX) {
+			goto out;
+		} else if (err < 0 || err != XDP_PASS) {
+			page_frag_alloc_abort(alloc_frag, buflen);
 			goto out;
+		}

 		pad = xdp.data - xdp.data_hard_start;
 		len = xdp.data_end - xdp.data;
@@ -1734,7 +1726,7 @@ static struct sk_buff *tun_build_skb(struct tun_struct *tun,
 	rcu_read_unlock();
 	local_bh_enable();

-	return __tun_build_skb(tfile, alloc_frag, buf, buflen, len, pad);
+	return __tun_build_skb(tfile, buf, buflen, len, pad);

 out:
 	bpf_net_ctx_clear(bpf_net_ctx);


> 
>>  void page_frag_free_va(void *addr);
>>  
>>  #endif
>> diff --git a/mm/page_frag_cache.c b/mm/page_frag_cache.c

...

>> +static struct page *__page_frag_cache_reload(struct page_frag_cache *nc,
>> +					     gfp_t gfp_mask)
>>  {
>> +	struct page *page;
>> +
>>  	if (likely(nc->encoded_va)) {
>> -		if (__page_frag_cache_reuse(nc->encoded_va, nc->pagecnt_bias))
>> +		page = __page_frag_cache_reuse(nc->encoded_va, nc->pagecnt_bias);
>> +		if (page)
>>  			goto out;
>>  	}
>>  
>> -	if (unlikely(!__page_frag_cache_refill(nc, gfp_mask)))
>> -		return false;
>> +	page = __page_frag_cache_refill(nc, gfp_mask);
>> +	if (unlikely(!page))
>> +		return NULL;
>>  
>>  out:
>>  	/* reset page count bias and remaining to start of new frag */
>>  	nc->pagecnt_bias = PAGE_FRAG_CACHE_MAX_SIZE + 1;
>>  	nc->remaining = page_frag_cache_page_size(nc->encoded_va);
>> -	return true;
>> +	return page;
>> +}
>> +
> 
> None of the functions above need to be returning page.

Are you still suggesting to always use virt_to_page() even when it is
not really necessary? why not return the page here to avoid the
virt_to_page()?

> 
>> +void *page_frag_alloc_va_prepare(struct page_frag_cache *nc,
>> +				 unsigned int *fragsz, gfp_t gfp)
>> +{
>> +	unsigned int remaining = nc->remaining;
>> +
>> +	VM_BUG_ON(!*fragsz);
>> +	if (likely(remaining >= *fragsz)) {
>> +		unsigned long encoded_va = nc->encoded_va;
>> +
>> +		*fragsz = remaining;
>> +
>> +		return encoded_page_address(encoded_va) +
>> +			(page_frag_cache_page_size(encoded_va) - remaining);
>> +	}
>> +
>> +	if (unlikely(*fragsz > PAGE_SIZE))
>> +		return NULL;
>> +
>> +	/* When reload fails, nc->encoded_va and nc->remaining are both reset
>> +	 * to zero, so there is no need to check the return value here.
>> +	 */
>> +	__page_frag_cache_reload(nc, gfp);
>> +
>> +	*fragsz = nc->remaining;
>> +	return encoded_page_address(nc->encoded_va);
>> +}
>> +EXPORT_SYMBOL(page_frag_alloc_va_prepare);

...

>> +struct page *page_frag_alloc_pg(struct page_frag_cache *nc,
>> +				unsigned int *offset, unsigned int fragsz,
>> +				gfp_t gfp)
>> +{
>> +	unsigned int remaining = nc->remaining;
>> +	struct page *page;
>> +
>> +	VM_BUG_ON(!fragsz);
>> +	if (likely(remaining >= fragsz)) {
>> +		unsigned long encoded_va = nc->encoded_va;
>> +
>> +		*offset = page_frag_cache_page_size(encoded_va) -
>> +				remaining;
>> +
>> +		return virt_to_page((void *)encoded_va);
>> +	}
>> +
>> +	if (unlikely(fragsz > PAGE_SIZE))
>> +		return NULL;
>> +
>> +	page = __page_frag_cache_reload(nc, gfp);
>> +	if (unlikely(!page))
>> +		return NULL;
>> +
>> +	*offset = 0;
>> +	nc->remaining = remaining - fragsz;
>> +	nc->pagecnt_bias--;
>> +
>> +	return page;
>>  }
>> +EXPORT_SYMBOL(page_frag_alloc_pg);
> 
> Again, this isn't returning a page. It is essentially returning a
> bio_vec without calling it as such. You might as well pass the bio_vec
> pointer as an argument and just have it populate it directly.

I really don't think your bio_vec suggestion make much sense  for now as
the reason mentioned in below:

"Through a quick look, there seems to be at least three structs which have
similar values: struct bio_vec & struct skb_frag & struct page_frag.

As your above agrument about using bio_vec, it seems it is ok to use any
one of them as each one of them seems to have almost all the values we
are using?

Personally, my preference over them: 'struct page_frag' > 'struct skb_frag'
> 'struct bio_vec', as the naming of 'struct page_frag' seems to best match
the page_frag API, 'struct skb_frag' is the second preference because we
mostly need to fill skb frag anyway, and 'struct bio_vec' is the last
preference because it just happen to have almost all the values needed.

Is there any specific reason other than the above "almost all the values you
are using are exposed by that structure already " that you prefer bio_vec?"

1. https://lore.kernel.org/all/ca6be29e-ab53-4673-9624-90d41616a154@huawei.com/

> 

Re: [PATCH net-next v13 11/14] mm: page_frag: introduce prepare/probe/commit API

[Alexander Duyck]

On Wed, Aug 14, 2024 at 8:05 PM Yunsheng Lin <linyunsheng@huawei.com> wrote:
>
> On 2024/8/15 5:00, Alexander H Duyck wrote:

...

> >> +static inline void page_frag_alloc_abort(struct page_frag_cache *nc,
> >> +                                     unsigned int fragsz)
> >> +{
> >> +    nc->pagecnt_bias++;
> >> +    nc->remaining += fragsz;
> >> +}
> >> +
> >
> > This doesn't add up. Why would you need abort if you have commit? Isn't
> > this more of a revert? I wouldn't think that would be valid as it is
> > possible you took some sort of action that might have resulted in this
> > memory already being shared. We shouldn't allow rewinding the offset
> > pointer without knowing that there are no other entities sharing the
> > page.
>
> This is used for __tun_build_skb() in drivers/net/tun.c as below, mainly
> used to avoid performance penalty for XDP drop case:

Yeah, I reviewed that patch. As I said there, rewinding the offset
should be avoided unless you can verify you are the only owner of the
page as you have no guarantees that somebody else didn't take an
access to the page/data to send it off somewhere else. Once you expose
the page to any other entity it should be written off or committed in
your case and you should move on to the next block.


>
> >> +static struct page *__page_frag_cache_reload(struct page_frag_cache *nc,
> >> +                                         gfp_t gfp_mask)
> >>  {
> >> +    struct page *page;
> >> +
> >>      if (likely(nc->encoded_va)) {
> >> -            if (__page_frag_cache_reuse(nc->encoded_va, nc->pagecnt_bias))
> >> +            page = __page_frag_cache_reuse(nc->encoded_va, nc->pagecnt_bias);
> >> +            if (page)
> >>                      goto out;
> >>      }
> >>
> >> -    if (unlikely(!__page_frag_cache_refill(nc, gfp_mask)))
> >> -            return false;
> >> +    page = __page_frag_cache_refill(nc, gfp_mask);
> >> +    if (unlikely(!page))
> >> +            return NULL;
> >>
> >>  out:
> >>      /* reset page count bias and remaining to start of new frag */
> >>      nc->pagecnt_bias = PAGE_FRAG_CACHE_MAX_SIZE + 1;
> >>      nc->remaining = page_frag_cache_page_size(nc->encoded_va);
> >> -    return true;
> >> +    return page;
> >> +}
> >> +
> >
> > None of the functions above need to be returning page.
>
> Are you still suggesting to always use virt_to_page() even when it is
> not really necessary? why not return the page here to avoid the
> virt_to_page()?

Yes. The likelihood of you needing to pass this out as a page should
be low as most cases will just be you using the virtual address
anyway. You are essentially trading off branching for not having to
use virt_to_page. It is unnecessary optimization.


>
> >> +struct page *page_frag_alloc_pg(struct page_frag_cache *nc,
> >> +                            unsigned int *offset, unsigned int fragsz,
> >> +                            gfp_t gfp)
> >> +{
> >> +    unsigned int remaining = nc->remaining;
> >> +    struct page *page;
> >> +
> >> +    VM_BUG_ON(!fragsz);
> >> +    if (likely(remaining >= fragsz)) {
> >> +            unsigned long encoded_va = nc->encoded_va;
> >> +
> >> +            *offset = page_frag_cache_page_size(encoded_va) -
> >> +                            remaining;
> >> +
> >> +            return virt_to_page((void *)encoded_va);
> >> +    }
> >> +
> >> +    if (unlikely(fragsz > PAGE_SIZE))
> >> +            return NULL;
> >> +
> >> +    page = __page_frag_cache_reload(nc, gfp);
> >> +    if (unlikely(!page))
> >> +            return NULL;
> >> +
> >> +    *offset = 0;
> >> +    nc->remaining = remaining - fragsz;
> >> +    nc->pagecnt_bias--;
> >> +
> >> +    return page;
> >>  }
> >> +EXPORT_SYMBOL(page_frag_alloc_pg);
> >
> > Again, this isn't returning a page. It is essentially returning a
> > bio_vec without calling it as such. You might as well pass the bio_vec
> > pointer as an argument and just have it populate it directly.
>
> I really don't think your bio_vec suggestion make much sense  for now as
> the reason mentioned in below:
>
> "Through a quick look, there seems to be at least three structs which have
> similar values: struct bio_vec & struct skb_frag & struct page_frag.
>
> As your above agrument about using bio_vec, it seems it is ok to use any
> one of them as each one of them seems to have almost all the values we
> are using?
>
> Personally, my preference over them: 'struct page_frag' > 'struct skb_frag'
> > 'struct bio_vec', as the naming of 'struct page_frag' seems to best match
> the page_frag API, 'struct skb_frag' is the second preference because we
> mostly need to fill skb frag anyway, and 'struct bio_vec' is the last
> preference because it just happen to have almost all the values needed.

That is why I said I would be okay with us passing page_frag in patch
12 after looking closer at the code. The fact is it should make the
review of that patch set much easier if you essentially just pass the
page_frag back out of the call. Then it could be used in exactly the
same way it was before and should reduce the total number of lines of
code that need to be changed.

> Is there any specific reason other than the above "almost all the values you
> are using are exposed by that structure already " that you prefer bio_vec?"
>
> 1. https://lore.kernel.org/all/ca6be29e-ab53-4673-9624-90d41616a154@huawei.com/

My reason for preferring bio_vec is that of the 3 it is the most setup
to be used as a local variable versus something stored in a struct
such as page_frag or used for some specialty user case such as
skb_frag_t. In addition it already has a set of helpers for converting
it to a virtual address or copying data to and from it which would
make it easier to get rid of a bunch of duplicate code.

Re: [PATCH net-next v13 11/14] mm: page_frag: introduce prepare/probe/commit API

[Yunsheng Lin]

On 2024/8/15 23:25, Alexander Duyck wrote:
> On Wed, Aug 14, 2024 at 8:05 PM Yunsheng Lin <linyunsheng@huawei.com> wrote:
>>
>> On 2024/8/15 5:00, Alexander H Duyck wrote:
> 
> ...
> 
>>>> +static inline void page_frag_alloc_abort(struct page_frag_cache *nc,
>>>> +                                     unsigned int fragsz)
>>>> +{
>>>> +    nc->pagecnt_bias++;
>>>> +    nc->remaining += fragsz;
>>>> +}
>>>> +
>>>
>>> This doesn't add up. Why would you need abort if you have commit? Isn't
>>> this more of a revert? I wouldn't think that would be valid as it is
>>> possible you took some sort of action that might have resulted in this
>>> memory already being shared. We shouldn't allow rewinding the offset
>>> pointer without knowing that there are no other entities sharing the
>>> page.
>>
>> This is used for __tun_build_skb() in drivers/net/tun.c as below, mainly
>> used to avoid performance penalty for XDP drop case:
> 
> Yeah, I reviewed that patch. As I said there, rewinding the offset
> should be avoided unless you can verify you are the only owner of the
> page as you have no guarantees that somebody else didn't take an
> access to the page/data to send it off somewhere else. Once you expose
> the page to any other entity it should be written off or committed in
> your case and you should move on to the next block.

Yes, the expectation is that somebody else didn't take an access to the
page/data to send it off somewhere else between page_frag_alloc_va()
and page_frag_alloc_abort(), did you see expectation was broken in that
patch? If yes, we should fix that by using page_frag_free_va() related
API instead of using page_frag_alloc_abort().

> 
> 
>>
>>>> +static struct page *__page_frag_cache_reload(struct page_frag_cache *nc,
>>>> +                                         gfp_t gfp_mask)
>>>>  {
>>>> +    struct page *page;
>>>> +
>>>>      if (likely(nc->encoded_va)) {
>>>> -            if (__page_frag_cache_reuse(nc->encoded_va, nc->pagecnt_bias))
>>>> +            page = __page_frag_cache_reuse(nc->encoded_va, nc->pagecnt_bias);
>>>> +            if (page)
>>>>                      goto out;
>>>>      }
>>>>
>>>> -    if (unlikely(!__page_frag_cache_refill(nc, gfp_mask)))
>>>> -            return false;
>>>> +    page = __page_frag_cache_refill(nc, gfp_mask);
>>>> +    if (unlikely(!page))
>>>> +            return NULL;
>>>>
>>>>  out:
>>>>      /* reset page count bias and remaining to start of new frag */
>>>>      nc->pagecnt_bias = PAGE_FRAG_CACHE_MAX_SIZE + 1;
>>>>      nc->remaining = page_frag_cache_page_size(nc->encoded_va);
>>>> -    return true;
>>>> +    return page;
>>>> +}
>>>> +
>>>
>>> None of the functions above need to be returning page.
>>
>> Are you still suggesting to always use virt_to_page() even when it is
>> not really necessary? why not return the page here to avoid the
>> virt_to_page()?
> 
> Yes. The likelihood of you needing to pass this out as a page should
> be low as most cases will just be you using the virtual address
> anyway. You are essentially trading off branching for not having to
> use virt_to_page. It is unnecessary optimization.

As my understanding, I am not trading off branching for not having to
use virt_to_page, the branching is already needed no matter we utilize
it to avoid calling virt_to_page() or not, please be more specific about
which branching is traded off for not having to use virt_to_page() here.


> 
> 
>>
>>>> +struct page *page_frag_alloc_pg(struct page_frag_cache *nc,
>>>> +                            unsigned int *offset, unsigned int fragsz,
>>>> +                            gfp_t gfp)
>>>> +{
>>>> +    unsigned int remaining = nc->remaining;
>>>> +    struct page *page;
>>>> +
>>>> +    VM_BUG_ON(!fragsz);
>>>> +    if (likely(remaining >= fragsz)) {
>>>> +            unsigned long encoded_va = nc->encoded_va;
>>>> +
>>>> +            *offset = page_frag_cache_page_size(encoded_va) -
>>>> +                            remaining;
>>>> +
>>>> +            return virt_to_page((void *)encoded_va);
>>>> +    }
>>>> +
>>>> +    if (unlikely(fragsz > PAGE_SIZE))
>>>> +            return NULL;
>>>> +
>>>> +    page = __page_frag_cache_reload(nc, gfp);
>>>> +    if (unlikely(!page))
>>>> +            return NULL;
>>>> +
>>>> +    *offset = 0;
>>>> +    nc->remaining = remaining - fragsz;
>>>> +    nc->pagecnt_bias--;
>>>> +
>>>> +    return page;
>>>>  }
>>>> +EXPORT_SYMBOL(page_frag_alloc_pg);
>>>
>>> Again, this isn't returning a page. It is essentially returning a
>>> bio_vec without calling it as such. You might as well pass the bio_vec
>>> pointer as an argument and just have it populate it directly.
>>
>> I really don't think your bio_vec suggestion make much sense  for now as
>> the reason mentioned in below:
>>
>> "Through a quick look, there seems to be at least three structs which have
>> similar values: struct bio_vec & struct skb_frag & struct page_frag.
>>
>> As your above agrument about using bio_vec, it seems it is ok to use any
>> one of them as each one of them seems to have almost all the values we
>> are using?
>>
>> Personally, my preference over them: 'struct page_frag' > 'struct skb_frag'
>>> 'struct bio_vec', as the naming of 'struct page_frag' seems to best match
>> the page_frag API, 'struct skb_frag' is the second preference because we
>> mostly need to fill skb frag anyway, and 'struct bio_vec' is the last
>> preference because it just happen to have almost all the values needed.
> 
> That is why I said I would be okay with us passing page_frag in patch
> 12 after looking closer at the code. The fact is it should make the
> review of that patch set much easier if you essentially just pass the
> page_frag back out of the call. Then it could be used in exactly the
> same way it was before and should reduce the total number of lines of
> code that need to be changed.

So the your suggestion changed to something like below?

int page_frag_alloc_pfrag(struct page_frag_cache *nc, struct page_frag *pfrag);

The API naming of 'page_frag_alloc_pfrag' seems a little odd to me, any better
one in your mind?

> 
>> Is there any specific reason other than the above "almost all the values you
>> are using are exposed by that structure already " that you prefer bio_vec?"
>>
>> 1. https://lore.kernel.org/all/ca6be29e-ab53-4673-9624-90d41616a154@huawei.com/
> 
> My reason for preferring bio_vec is that of the 3 it is the most setup
> to be used as a local variable versus something stored in a struct
> such as page_frag or used for some specialty user case such as
> skb_frag_t. In addition it already has a set of helpers for converting
> it to a virtual address or copying data to and from it which would
> make it easier to get rid of a bunch of duplicate code.

Re: [PATCH net-next v13 11/14] mm: page_frag: introduce prepare/probe/commit API

[Alexander Duyck]

On Fri, Aug 16, 2024 at 5:01 AM Yunsheng Lin <linyunsheng@huawei.com> wrote:
>
> On 2024/8/15 23:25, Alexander Duyck wrote:
> > On Wed, Aug 14, 2024 at 8:05 PM Yunsheng Lin <linyunsheng@huawei.com> wrote:
> >>
> >> On 2024/8/15 5:00, Alexander H Duyck wrote:
> >
> > ...
> >
> >>>> +static inline void page_frag_alloc_abort(struct page_frag_cache *nc,
> >>>> +                                     unsigned int fragsz)
> >>>> +{
> >>>> +    nc->pagecnt_bias++;
> >>>> +    nc->remaining += fragsz;
> >>>> +}
> >>>> +
> >>>
> >>> This doesn't add up. Why would you need abort if you have commit? Isn't
> >>> this more of a revert? I wouldn't think that would be valid as it is
> >>> possible you took some sort of action that might have resulted in this
> >>> memory already being shared. We shouldn't allow rewinding the offset
> >>> pointer without knowing that there are no other entities sharing the
> >>> page.
> >>
> >> This is used for __tun_build_skb() in drivers/net/tun.c as below, mainly
> >> used to avoid performance penalty for XDP drop case:
> >
> > Yeah, I reviewed that patch. As I said there, rewinding the offset
> > should be avoided unless you can verify you are the only owner of the
> > page as you have no guarantees that somebody else didn't take an
> > access to the page/data to send it off somewhere else. Once you expose
> > the page to any other entity it should be written off or committed in
> > your case and you should move on to the next block.
>
> Yes, the expectation is that somebody else didn't take an access to the
> page/data to send it off somewhere else between page_frag_alloc_va()
> and page_frag_alloc_abort(), did you see expectation was broken in that
> patch? If yes, we should fix that by using page_frag_free_va() related
> API instead of using page_frag_alloc_abort().

The problem is when you expose it to XDP there are a number of
different paths it can take. As such you shouldn't be expecting XDP to
not do something like that. Basically you have to check the reference
count before you can rewind the page.

> >
> >
> >>
> >>>> +static struct page *__page_frag_cache_reload(struct page_frag_cache *nc,
> >>>> +                                         gfp_t gfp_mask)
> >>>>  {
> >>>> +    struct page *page;
> >>>> +
> >>>>      if (likely(nc->encoded_va)) {
> >>>> -            if (__page_frag_cache_reuse(nc->encoded_va, nc->pagecnt_bias))
> >>>> +            page = __page_frag_cache_reuse(nc->encoded_va, nc->pagecnt_bias);
> >>>> +            if (page)
> >>>>                      goto out;
> >>>>      }
> >>>>
> >>>> -    if (unlikely(!__page_frag_cache_refill(nc, gfp_mask)))
> >>>> -            return false;
> >>>> +    page = __page_frag_cache_refill(nc, gfp_mask);
> >>>> +    if (unlikely(!page))
> >>>> +            return NULL;
> >>>>
> >>>>  out:
> >>>>      /* reset page count bias and remaining to start of new frag */
> >>>>      nc->pagecnt_bias = PAGE_FRAG_CACHE_MAX_SIZE + 1;
> >>>>      nc->remaining = page_frag_cache_page_size(nc->encoded_va);
> >>>> -    return true;
> >>>> +    return page;
> >>>> +}
> >>>> +
> >>>
> >>> None of the functions above need to be returning page.
> >>
> >> Are you still suggesting to always use virt_to_page() even when it is
> >> not really necessary? why not return the page here to avoid the
> >> virt_to_page()?
> >
> > Yes. The likelihood of you needing to pass this out as a page should
> > be low as most cases will just be you using the virtual address
> > anyway. You are essentially trading off branching for not having to
> > use virt_to_page. It is unnecessary optimization.
>
> As my understanding, I am not trading off branching for not having to
> use virt_to_page, the branching is already needed no matter we utilize
> it to avoid calling virt_to_page() or not, please be more specific about
> which branching is traded off for not having to use virt_to_page() here.

The virt_to_page overhead isn't that high. It would be better to just
use a consistent path rather than try to optimize for an unlikely
branch in your datapath.

> >
> >
> >>
> >>>> +struct page *page_frag_alloc_pg(struct page_frag_cache *nc,
> >>>> +                            unsigned int *offset, unsigned int fragsz,
> >>>> +                            gfp_t gfp)
> >>>> +{
> >>>> +    unsigned int remaining = nc->remaining;
> >>>> +    struct page *page;
> >>>> +
> >>>> +    VM_BUG_ON(!fragsz);
> >>>> +    if (likely(remaining >= fragsz)) {
> >>>> +            unsigned long encoded_va = nc->encoded_va;
> >>>> +
> >>>> +            *offset = page_frag_cache_page_size(encoded_va) -
> >>>> +                            remaining;
> >>>> +
> >>>> +            return virt_to_page((void *)encoded_va);
> >>>> +    }
> >>>> +
> >>>> +    if (unlikely(fragsz > PAGE_SIZE))
> >>>> +            return NULL;
> >>>> +
> >>>> +    page = __page_frag_cache_reload(nc, gfp);
> >>>> +    if (unlikely(!page))
> >>>> +            return NULL;
> >>>> +
> >>>> +    *offset = 0;
> >>>> +    nc->remaining = remaining - fragsz;
> >>>> +    nc->pagecnt_bias--;
> >>>> +
> >>>> +    return page;
> >>>>  }
> >>>> +EXPORT_SYMBOL(page_frag_alloc_pg);
> >>>
> >>> Again, this isn't returning a page. It is essentially returning a
> >>> bio_vec without calling it as such. You might as well pass the bio_vec
> >>> pointer as an argument and just have it populate it directly.
> >>
> >> I really don't think your bio_vec suggestion make much sense  for now as
> >> the reason mentioned in below:
> >>
> >> "Through a quick look, there seems to be at least three structs which have
> >> similar values: struct bio_vec & struct skb_frag & struct page_frag.
> >>
> >> As your above agrument about using bio_vec, it seems it is ok to use any
> >> one of them as each one of them seems to have almost all the values we
> >> are using?
> >>
> >> Personally, my preference over them: 'struct page_frag' > 'struct skb_frag'
> >>> 'struct bio_vec', as the naming of 'struct page_frag' seems to best match
> >> the page_frag API, 'struct skb_frag' is the second preference because we
> >> mostly need to fill skb frag anyway, and 'struct bio_vec' is the last
> >> preference because it just happen to have almost all the values needed.
> >
> > That is why I said I would be okay with us passing page_frag in patch
> > 12 after looking closer at the code. The fact is it should make the
> > review of that patch set much easier if you essentially just pass the
> > page_frag back out of the call. Then it could be used in exactly the
> > same way it was before and should reduce the total number of lines of
> > code that need to be changed.
>
> So the your suggestion changed to something like below?
>
> int page_frag_alloc_pfrag(struct page_frag_cache *nc, struct page_frag *pfrag);
>
> The API naming of 'page_frag_alloc_pfrag' seems a little odd to me, any better
> one in your mind?

Well at this point we are populating/getting/pulling a page frag from
the page frag cache. Maybe look for a word other than alloc such as
populate. Essentially what you are doing is populating the pfrag from
the frag cache, although I thought there was a size value you passed
for that isn't there?

Re: [PATCH net-next v13 11/14] mm: page_frag: introduce prepare/probe/commit API

[Yunsheng Lin]

On 2024/8/19 23:52, Alexander Duyck wrote:

>>
>> Yes, the expectation is that somebody else didn't take an access to the
>> page/data to send it off somewhere else between page_frag_alloc_va()
>> and page_frag_alloc_abort(), did you see expectation was broken in that
>> patch? If yes, we should fix that by using page_frag_free_va() related
>> API instead of using page_frag_alloc_abort().
> 
> The problem is when you expose it to XDP there are a number of
> different paths it can take. As such you shouldn't be expecting XDP to
> not do something like that. Basically you have to check the reference

Even if XDP operations like xdp_do_redirect() or tun_xdp_xmit() return
failure, we still can not do that? It seems odd that happens.
If not, can we use page_frag_alloc_abort() with fragsz being zero to avoid
atomic operation?

> count before you can rewind the page.
> 
>>>
>>>
>>>>
>>>>>> +static struct page *__page_frag_cache_reload(struct page_frag_cache *nc,
>>>>>> +                                         gfp_t gfp_mask)
>>>>>>  {
>>>>>> +    struct page *page;
>>>>>> +
>>>>>>      if (likely(nc->encoded_va)) {
>>>>>> -            if (__page_frag_cache_reuse(nc->encoded_va, nc->pagecnt_bias))
>>>>>> +            page = __page_frag_cache_reuse(nc->encoded_va, nc->pagecnt_bias);
>>>>>> +            if (page)
>>>>>>                      goto out;
>>>>>>      }
>>>>>>
>>>>>> -    if (unlikely(!__page_frag_cache_refill(nc, gfp_mask)))
>>>>>> -            return false;
>>>>>> +    page = __page_frag_cache_refill(nc, gfp_mask);
>>>>>> +    if (unlikely(!page))
>>>>>> +            return NULL;
>>>>>>
>>>>>>  out:
>>>>>>      /* reset page count bias and remaining to start of new frag */
>>>>>>      nc->pagecnt_bias = PAGE_FRAG_CACHE_MAX_SIZE + 1;
>>>>>>      nc->remaining = page_frag_cache_page_size(nc->encoded_va);
>>>>>> -    return true;
>>>>>> +    return page;
>>>>>> +}
>>>>>> +
>>>>>
>>>>> None of the functions above need to be returning page.
>>>>
>>>> Are you still suggesting to always use virt_to_page() even when it is
>>>> not really necessary? why not return the page here to avoid the
>>>> virt_to_page()?
>>>
>>> Yes. The likelihood of you needing to pass this out as a page should
>>> be low as most cases will just be you using the virtual address
>>> anyway. You are essentially trading off branching for not having to
>>> use virt_to_page. It is unnecessary optimization.
>>
>> As my understanding, I am not trading off branching for not having to
>> use virt_to_page, the branching is already needed no matter we utilize
>> it to avoid calling virt_to_page() or not, please be more specific about
>> which branching is traded off for not having to use virt_to_page() here.
> 
> The virt_to_page overhead isn't that high. It would be better to just
> use a consistent path rather than try to optimize for an unlikely
> branch in your datapath.

I am not sure if I understand what do you mean by 'consistent path' here.
If I understand your comment correctly, the path is already not consistent
to avoid having to fetch size multiple times multiple ways as mentioned in
[1]. As below, doesn't it seems nature to avoid virt_to_page() calling while
avoiding page_frag_cache_page_size() calling, even if it is an unlikely case
as you mentioned:

struct page *page_frag_alloc_pg(struct page_frag_cache *nc,
                                unsigned int *offset, unsigned int fragsz,
                                gfp_t gfp)
{
        unsigned int remaining = nc->remaining;
        struct page *page;

        VM_BUG_ON(!fragsz);
        if (likely(remaining >= fragsz)) {
                unsigned long encoded_va = nc->encoded_va;

                *offset = page_frag_cache_page_size(encoded_va) -
                                remaining;

                return virt_to_page((void *)encoded_va);
        }

        if (unlikely(fragsz > PAGE_SIZE))
                return NULL;

        page = __page_frag_cache_reload(nc, gfp);
        if (unlikely(!page))
                return NULL;

        *offset = 0;
        nc->remaining -= fragsz;
        nc->pagecnt_bias--;

        return page;
}

1. https://lore.kernel.org/all/CAKgT0UeQ9gwYo7qttak0UgXC9+kunO2gedm_yjtPiMk4VJp9yQ@mail.gmail.com/

> 
>>>
>>>
>>>>
>>>>>> +struct page *page_frag_alloc_pg(struct page_frag_cache *nc,
>>>>>> +                            unsigned int *offset, unsigned int fragsz,
>>>>>> +                            gfp_t gfp)
>>>>>> +{
>>>>>> +    unsigned int remaining = nc->remaining;
>>>>>> +    struct page *page;
>>>>>> +
>>>>>> +    VM_BUG_ON(!fragsz);
>>>>>> +    if (likely(remaining >= fragsz)) {
>>>>>> +            unsigned long encoded_va = nc->encoded_va;
>>>>>> +
>>>>>> +            *offset = page_frag_cache_page_size(encoded_va) -
>>>>>> +                            remaining;
>>>>>> +
>>>>>> +            return virt_to_page((void *)encoded_va);
>>>>>> +    }
>>>>>> +
>>>>>> +    if (unlikely(fragsz > PAGE_SIZE))
>>>>>> +            return NULL;
>>>>>> +
>>>>>> +    page = __page_frag_cache_reload(nc, gfp);
>>>>>> +    if (unlikely(!page))
>>>>>> +            return NULL;
>>>>>> +
>>>>>> +    *offset = 0;
>>>>>> +    nc->remaining = remaining - fragsz;
>>>>>> +    nc->pagecnt_bias--;
>>>>>> +
>>>>>> +    return page;
>>>>>>  }
>>>>>> +EXPORT_SYMBOL(page_frag_alloc_pg);
>>>>>
>>>>> Again, this isn't returning a page. It is essentially returning a
>>>>> bio_vec without calling it as such. You might as well pass the bio_vec
>>>>> pointer as an argument and just have it populate it directly.
>>>>
>>>> I really don't think your bio_vec suggestion make much sense  for now as
>>>> the reason mentioned in below:
>>>>
>>>> "Through a quick look, there seems to be at least three structs which have
>>>> similar values: struct bio_vec & struct skb_frag & struct page_frag.
>>>>
>>>> As your above agrument about using bio_vec, it seems it is ok to use any
>>>> one of them as each one of them seems to have almost all the values we
>>>> are using?
>>>>
>>>> Personally, my preference over them: 'struct page_frag' > 'struct skb_frag'
>>>>> 'struct bio_vec', as the naming of 'struct page_frag' seems to best match
>>>> the page_frag API, 'struct skb_frag' is the second preference because we
>>>> mostly need to fill skb frag anyway, and 'struct bio_vec' is the last
>>>> preference because it just happen to have almost all the values needed.
>>>
>>> That is why I said I would be okay with us passing page_frag in patch
>>> 12 after looking closer at the code. The fact is it should make the
>>> review of that patch set much easier if you essentially just pass the
>>> page_frag back out of the call. Then it could be used in exactly the
>>> same way it was before and should reduce the total number of lines of
>>> code that need to be changed.
>>
>> So the your suggestion changed to something like below?
>>
>> int page_frag_alloc_pfrag(struct page_frag_cache *nc, struct page_frag *pfrag);
>>
>> The API naming of 'page_frag_alloc_pfrag' seems a little odd to me, any better
>> one in your mind?
> 
> Well at this point we are populating/getting/pulling a page frag from
> the page frag cache. Maybe look for a word other than alloc such as
> populate. Essentially what you are doing is populating the pfrag from
> the frag cache, although I thought there was a size value you passed
> for that isn't there?

'struct page_frag' does have a size field, but I am not sure if I
understand what do you mean by  'although I thought there was a size
value you passed for that isn't there?‘ yet.