linux-kernel - Re: [PATCH] docs/vm/transhuge: Fix few trivial typos

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Thu, 6 Apr 2017 10:04:43 -0700
From:   Randy Dunlap <rdunlap@...radead.org>
To:     SeongJae Park <sj38.park@...il.com>, corbet@....net
Cc:     akpm@...ux-foundation.org, rientjes@...gle.com,
        linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] docs/vm/transhuge: Fix few trivial typos

On 04/05/17 14:02, SeongJae Park wrote:
> Signed-off-by: SeongJae Park <sj38.park@...il.com>
> ---
>  Documentation/vm/transhuge.txt | 10 +++++-----
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/Documentation/vm/transhuge.txt b/Documentation/vm/transhuge.txt
> index cd28d5ee5273..4e22578e50d3 100644
> --- a/Documentation/vm/transhuge.txt
> +++ b/Documentation/vm/transhuge.txt
> @@ -266,7 +266,7 @@ for each mapping.
>  
>  The number of file transparent huge pages mapped to userspace is available
>  by reading ShmemPmdMapped and ShmemHugePages fields in /proc/meminfo.
> -To identify what applications are mapping file  transparent huge pages, it
> +To identify what applications are mapping file transparent huge pages, it
>  is necessary to read /proc/PID/smaps and count the FileHugeMapped fields
>  for each mapping.
>  
> @@ -292,7 +292,7 @@ thp_collapse_alloc_failed is incremented if khugepaged found a range
>  	the allocation.
>  
>  thp_file_alloc is incremented every time a file huge page is successfully
> -i	allocated.
> +	allocated.
>  
>  thp_file_mapped is incremented every time a file huge page is mapped into
>  	user address space.
> @@ -501,7 +501,7 @@ scanner can get reference to a page is get_page_unless_zero().
>  
>  All tail pages have zero ->_refcount until atomic_add(). This prevents the
>  scanner from getting a reference to the tail page up to that point. After the
> -atomic_add() we don't care about the ->_refcount value.  We already known how
> +atomic_add() we don't care about the ->_refcount value. We already known how
>  many references should be uncharged from the head page.
>  
>  For head page get_page_unless_zero() will succeed and we don't mind. It's
> @@ -519,8 +519,8 @@ comes. Splitting will free up unused subpages.
>  
>  Splitting the page right away is not an option due to locking context in
>  the place where we can detect partial unmap. It's also might be
> -counterproductive since in many cases partial unmap unmap happens during
> -exit(2) if an THP crosses VMA boundary.
> +counterproductive since in many cases partial unmap happens during exit(2) if
> +an THP crosses VMA boundary.

   a THP
and maybe:
          crosses a VMA boundary.

>  
>  Function deferred_split_huge_page() is used to queue page for splitting.
>  The splitting itself will happen when we get memory pressure via shrinker
> 


-- 
~Randy