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] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 23 Oct 2014 09:19:31 +0900
From:	Gioh Kim <gioh.kim@....com>
To:	Pintu Kumar <pintu.k@...sung.com>, akpm@...ux-foundation.org,
	riel@...hat.com, aquini@...hat.com, paul.gortmaker@...driver.com,
	jmarchan@...hat.com, lcapitulino@...hat.com,
	kirill.shutemov@...ux.intel.com, m.szyprowski@...sung.com,
	aneesh.kumar@...ux.vnet.ibm.com, iamjoonsoo.kim@....com,
	mina86@...a86.com, lauraa@...eaurora.org, mgorman@...e.de,
	rientjes@...gle.com, hannes@...xchg.org, vbabka@...e.cz,
	sasha.levin@...cle.com, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org
CC:	pintu_agarwal@...oo.com, cpgs@...sung.com, vishnu.ps@...sung.com,
	rohit.kr@...sung.com, ed.savinay@...sung.com
Subject: Re: [PATCH v2 2/2] fs: proc: Include cma info in proc/meminfo



2014-10-22 ¿ÀÈÄ 11:06, Pintu Kumar ¾´ ±Û:
> This patch include CMA info (CMATotal, CMAFree) in /proc/meminfo.
> Currently, in a CMA enabled system, if somebody wants to know the
> total CMA size declared, there is no way to tell, other than the dmesg
> or /var/log/messages logs.
> With this patch we are showing the CMA info as part of meminfo, so that
> it can be determined at any point of time.
> This will be populated only when CMA is enabled.
> 
> Below is the sample output from a ARM based device with RAM:512MB and CMA:16MB.
> 
> MemTotal:         471172 kB
> MemFree:          111712 kB
> MemAvailable:     271172 kB
> .
> .
> .
> CmaTotal:          16384 kB
> CmaFree:            6144 kB
> 
> This patch also fix below checkpatch errors that were found during these changes.

Why don't you split patch for it?
I think there's a rule not to mix separate patchs.

> 
> ERROR: space required after that ',' (ctx:ExV)
> 199: FILE: fs/proc/meminfo.c:199:
> +       ,atomic_long_read(&num_poisoned_pages) << (PAGE_SHIFT - 10)
>          ^
> 
> ERROR: space required after that ',' (ctx:ExV)
> 202: FILE: fs/proc/meminfo.c:202:
> +       ,K(global_page_state(NR_ANON_TRANSPARENT_HUGEPAGES) *
>          ^
> 
> ERROR: space required after that ',' (ctx:ExV)
> 206: FILE: fs/proc/meminfo.c:206:
> +       ,K(totalcma_pages)
>          ^
> 
> total: 3 errors, 0 warnings, 2 checks, 236 lines checked
> 
> Signed-off-by: Pintu Kumar <pintu.k@...sung.com>
> Signed-off-by: Vishnu Pratap Singh <vishnu.ps@...sung.com>
> ---
>   fs/proc/meminfo.c |   15 +++++++++++++--
>   1 file changed, 13 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/proc/meminfo.c b/fs/proc/meminfo.c
> index aa1eee0..d3ebf2e 100644
> --- a/fs/proc/meminfo.c
> +++ b/fs/proc/meminfo.c
> @@ -12,6 +12,9 @@
>   #include <linux/vmstat.h>
>   #include <linux/atomic.h>
>   #include <linux/vmalloc.h>
> +#ifdef CONFIG_CMA
> +#include <linux/cma.h>
> +#endif
>   #include <asm/page.h>
>   #include <asm/pgtable.h>
>   #include "internal.h"
> @@ -138,6 +141,10 @@ static int meminfo_proc_show(struct seq_file *m, void *v)
>   #ifdef CONFIG_TRANSPARENT_HUGEPAGE
>   		"AnonHugePages:  %8lu kB\n"
>   #endif
> +#ifdef CONFIG_CMA
> +		"CmaTotal:       %8lu kB\n"
> +		"CmaFree:        %8lu kB\n"
> +#endif
>   		,
>   		K(i.totalram),
>   		K(i.freeram),
> @@ -187,12 +194,16 @@ static int meminfo_proc_show(struct seq_file *m, void *v)
>   		vmi.used >> 10,
>   		vmi.largest_chunk >> 10
>   #ifdef CONFIG_MEMORY_FAILURE
> -		,atomic_long_read(&num_poisoned_pages) << (PAGE_SHIFT - 10)
> +		, atomic_long_read(&num_poisoned_pages) << (PAGE_SHIFT - 10)
>   #endif
>   #ifdef CONFIG_TRANSPARENT_HUGEPAGE
> -		,K(global_page_state(NR_ANON_TRANSPARENT_HUGEPAGES) *
> +		, K(global_page_state(NR_ANON_TRANSPARENT_HUGEPAGES) *
>   		   HPAGE_PMD_NR)
>   #endif
> +#ifdef CONFIG_CMA
> +		, K(totalcma_pages)
> +		, K(global_page_state(NR_FREE_CMA_PAGES))
> +#endif
>   		);

Just for sure, are zoneinfo and pagetypeinfo not suitable?

I don't know HOTPLUG feature so I'm just asking for sure.
Does HOTPLUG not need printing message like this?

Thanks a lot.

>   
>   	hugetlb_report_meminfo(m);
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ