Currently, there is no fast mechanism to get the virtual memory size of
the current process from userspace. This information is available to the
user through several means, one being a linear search of the entire address
space. This is the method used by a component of the libhugetlb kernel
test, and using the mechanism proposed in this patch, the time complexity
of that test would be upgraded to constant time from linear time. This is
especially relevant on 64-bit architechtures where a linear search of
the address space could take an absurd amount of time. Using this
mechanism, the modification to the test component would be portable
across all architechtures.
Signed-off-by: Joel Savitz <[email protected]>
---
fs/proc/task_mmu.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index 92a91e7816d8..f64b9a949624 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -74,7 +74,10 @@ void task_mem(struct seq_file *m, struct mm_struct *mm)
seq_put_decimal_ull_width(m,
" kB\nVmPTE:\t", mm_pgtables_bytes(mm) >> 10, 8);
SEQ_PUT_DEC(" kB\nVmSwap:\t", swap);
- seq_puts(m, " kB\n");
+ SEQ_PUT_DEC(" kB\nVmSwap:\t", swap);
+ seq_put_decimal_ull_width(m,
+ " kB\nVmTaskSize:\t", TASK_SIZE >> 10, 8);
+ seq_puts(m, " kB\n");
hugetlb_report_usage(m, mm);
}
#undef SEQ_PUT_DEC
--
2.18.1
On Thu, Apr 25, 2019 at 04:57:47PM -0400, Joel Savitz wrote:
> Currently, there is no fast mechanism to get the virtual memory size of
> the current process from userspace. This information is available to the
> user through several means, one being a linear search of the entire address
> space. This is the method used by a component of the libhugetlb kernel
> test, and using the mechanism proposed in this patch, the time complexity
> of that test would be upgraded to constant time from linear time. This is
> especially relevant on 64-bit architechtures where a linear search of
> the address space could take an absurd amount of time. Using this
> mechanism, the modification to the test component would be portable
> across all architechtures.
>
> Signed-off-by: Joel Savitz <[email protected]>
> ---
> fs/proc/task_mmu.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
> index 92a91e7816d8..f64b9a949624 100644
> --- a/fs/proc/task_mmu.c
> +++ b/fs/proc/task_mmu.c
> @@ -74,7 +74,10 @@ void task_mem(struct seq_file *m, struct mm_struct *mm)
> seq_put_decimal_ull_width(m,
> " kB\nVmPTE:\t", mm_pgtables_bytes(mm) >> 10, 8);
> SEQ_PUT_DEC(" kB\nVmSwap:\t", swap);
> - seq_puts(m, " kB\n");
> + SEQ_PUT_DEC(" kB\nVmSwap:\t", swap);
> + seq_put_decimal_ull_width(m,
> + " kB\nVmTaskSize:\t", TASK_SIZE >> 10, 8);
> + seq_puts(m, " kB\n");
> hugetlb_report_usage(m, mm);
> }
> #undef SEQ_PUT_DEC
> --
> 2.18.1
>
Acked-by: Rafael Aquini <[email protected]>
On Thu, 25 Apr 2019 16:57:47 -0400 Joel Savitz <[email protected]> wrote:
> Currently, there is no fast mechanism to get the virtual memory size of
> the current process from userspace. This information is available to the
> user through several means, one being a linear search of the entire address
> space. This is the method used by a component of the libhugetlb kernel
> test, and using the mechanism proposed in this patch, the time complexity
> of that test would be upgraded to constant time from linear time. This is
> especially relevant on 64-bit architechtures where a linear search of
> the address space could take an absurd amount of time. Using this
> mechanism, the modification to the test component would be portable
> across all architechtures.
Please include all details on the observed performance improvements.
> fs/proc/task_mmu.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
Please update Documentation/filesystems/proc.txt.
On Thu, Apr 25, 2019 at 04:57:47PM -0400, Joel Savitz wrote:
> Currently, there is no fast mechanism to get the virtual memory size of
> the current process from userspace.
> --- a/fs/proc/task_mmu.c
> +++ b/fs/proc/task_mmu.c
> @@ -74,7 +74,10 @@ void task_mem(struct seq_file *m, struct mm_struct *mm)
> seq_put_decimal_ull_width(m,
> " kB\nVmPTE:\t", mm_pgtables_bytes(mm) >> 10, 8);
> SEQ_PUT_DEC(" kB\nVmSwap:\t", swap);
> - seq_puts(m, " kB\n");
> + SEQ_PUT_DEC(" kB\nVmSwap:\t", swap);
> + seq_put_decimal_ull_width(m,
> + " kB\nVmTaskSize:\t", TASK_SIZE >> 10, 8);
> + seq_puts(m, " kB\n");
TASK_SIZE accesses "current", while this function accesses any ->mm.
Can you turn this into prctl(2) aka "current" refugee camp?