| Message ID | 1556305328-2001-1-git-send-email-jsavitz@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v2] fs/proc: add VmTaskSize field to /proc/$$/status | expand |
On Fri, Apr 26, 2019 at 03:02:08PM -0400, Joel Savitz wrote: > In the mainline kernel, there is no quick mechanism to get the virtual > memory size of the current process from userspace. > > Despite the current state of affairs, this information is available to the > user through several means, one being a linear search of the entire address > space. This is an inefficient use of cpu cycles. > > A component of the libhugetlb kernel test does exactly this, and as > systems' address spaces increase beyond 32-bits, this method becomes > exceedingly tedious. > > For example, on a ppc64le system with a 47-bit address space, the linear > search causes the test to hang for some unknown amount of time. I > couldn't give you an exact number because I just ran it for about 10-20 > minutes and went to go do something else, probably to get coffee or > something, and when I came back, I just killed the test and patched it > to use this new mechanism. I re-ran my new version of the test using a > kernel with this patch, and of course it passed through the previously > bottlenecking codepath nearly instantaneously. > > This patched enabled me to upgrade an O(n) codepath to O(1) in an > architecture-independent manner. > > Signed-off-by: Joel Savitz <jsavitz@redhat.com> > --- > Documentation/filesystems/proc.txt | 2 ++ > fs/proc/task_mmu.c | 5 ++++- > 2 files changed, 6 insertions(+), 1 deletion(-) > > diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt > index 66cad5c86171..1c6a912e3975 100644 > --- a/Documentation/filesystems/proc.txt > +++ b/Documentation/filesystems/proc.txt > @@ -187,6 +187,7 @@ read the file /proc/PID/status: > VmLib: 1412 kB > VmPTE: 20 kb > VmSwap: 0 kB > + VmTaskSize: 137438953468 kB > HugetlbPages: 0 kB > CoreDumping: 0 > THP_enabled: 1 > @@ -263,6 +264,7 @@ Table 1-2: Contents of the status files (as of 4.19) > VmPTE size of page table entries > VmSwap amount of swap used by anonymous private data > (shmem swap usage is not included) > + VmTaskSize size of entire virtual address space of a process > HugetlbPages size of hugetlb memory portions > CoreDumping process's memory is currently being dumped > (killing the process may lead to a corrupted core) > diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c > index 95ca1fe7283c..0ddd51479f90 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 <aquini@redhat.com>
On Fri, Apr 26, 2019 at 03:02:08PM -0400, Joel Savitz wrote: > In the mainline kernel, there is no quick mechanism to get the virtual > memory size of the current process from userspace. > > Despite the current state of affairs, this information is available to the > user through several means, one being a linear search of the entire address > space. This is an inefficient use of cpu cycles. You can test only a few known per arch values. Linear search is a self inflicted wound. prctl(2) is more natural place and will also be arch neutral. > A component of the libhugetlb kernel test does exactly this, and as > systems' address spaces increase beyond 32-bits, this method becomes > exceedingly tedious. > For example, on a ppc64le system with a 47-bit address space, the linear > search causes the test to hang for some unknown amount of time. I > couldn't give you an exact number because I just ran it for about 10-20 > minutes and went to go do something else, probably to get coffee or > something, and when I came back, I just killed the test and patched it > to use this new mechanism. I re-ran my new version of the test using a > kernel with this patch, and of course it passed through the previously > bottlenecking codepath nearly instantaneously. > > This patched enabled me to upgrade an O(n) codepath to O(1) in an > architecture-independent manner. > --- 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"); All fields in this file are related to the task. New field related to "current" will stick like an eyesore.
Good point Alexey. Expect v3 shortly. Best, Joel Savitz On Sat, Apr 27, 2019 at 5:45 PM Alexey Dobriyan <adobriyan@gmail.com> wrote: > > On Fri, Apr 26, 2019 at 03:02:08PM -0400, Joel Savitz wrote: > > In the mainline kernel, there is no quick mechanism to get the virtual > > memory size of the current process from userspace. > > > > Despite the current state of affairs, this information is available to the > > user through several means, one being a linear search of the entire address > > space. This is an inefficient use of cpu cycles. > > You can test only a few known per arch values. Linear search is a self > inflicted wound. > > prctl(2) is more natural place and will also be arch neutral. > > > A component of the libhugetlb kernel test does exactly this, and as > > systems' address spaces increase beyond 32-bits, this method becomes > > exceedingly tedious. > > > For example, on a ppc64le system with a 47-bit address space, the linear > > search causes the test to hang for some unknown amount of time. I > > couldn't give you an exact number because I just ran it for about 10-20 > > minutes and went to go do something else, probably to get coffee or > > something, and when I came back, I just killed the test and patched it > > to use this new mechanism. I re-ran my new version of the test using a > > kernel with this patch, and of course it passed through the previously > > bottlenecking codepath nearly instantaneously. > > > > This patched enabled me to upgrade an O(n) codepath to O(1) in an > > architecture-independent manner. > > > --- 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"); > > All fields in this file are related to the task. New field related > to "current" will stick like an eyesore.
diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt index 66cad5c86171..1c6a912e3975 100644 --- a/Documentation/filesystems/proc.txt +++ b/Documentation/filesystems/proc.txt @@ -187,6 +187,7 @@ read the file /proc/PID/status: VmLib: 1412 kB VmPTE: 20 kb VmSwap: 0 kB + VmTaskSize: 137438953468 kB HugetlbPages: 0 kB CoreDumping: 0 THP_enabled: 1 @@ -263,6 +264,7 @@ Table 1-2: Contents of the status files (as of 4.19) VmPTE size of page table entries VmSwap amount of swap used by anonymous private data (shmem swap usage is not included) + VmTaskSize size of entire virtual address space of a process HugetlbPages size of hugetlb memory portions CoreDumping process's memory is currently being dumped (killing the process may lead to a corrupted core) diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c index 95ca1fe7283c..0ddd51479f90 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
In the mainline kernel, there is no quick mechanism to get the virtual memory size of the current process from userspace. Despite the current state of affairs, this information is available to the user through several means, one being a linear search of the entire address space. This is an inefficient use of cpu cycles. A component of the libhugetlb kernel test does exactly this, and as systems' address spaces increase beyond 32-bits, this method becomes exceedingly tedious. For example, on a ppc64le system with a 47-bit address space, the linear search causes the test to hang for some unknown amount of time. I couldn't give you an exact number because I just ran it for about 10-20 minutes and went to go do something else, probably to get coffee or something, and when I came back, I just killed the test and patched it to use this new mechanism. I re-ran my new version of the test using a kernel with this patch, and of course it passed through the previously bottlenecking codepath nearly instantaneously. This patched enabled me to upgrade an O(n) codepath to O(1) in an architecture-independent manner. Signed-off-by: Joel Savitz <jsavitz@redhat.com> --- Documentation/filesystems/proc.txt | 2 ++ fs/proc/task_mmu.c | 5 ++++- 2 files changed, 6 insertions(+), 1 deletion(-)