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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <544A2588.40802@lge.com>
Date:	Fri, 24 Oct 2014 19:10:16 +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-24 ¿ÀÈÄ 5:57, PINTU KUMAR ¾´ ±Û:
> Hi,
> 
> ----- Original Message -----
>> 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
>> Sent: Thursday, 23 October 2014 5:49 AM
>> 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.
>>
> 
> Last time when we submitted separate patches for checkpatch errors, it was
> suggested to
> Include these kinds of fixes along with some meaningful patches together.
> So, we included it in same patch.
> 
>>>
>>> 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 think zoneinfo shows only current free cma pages.
> Same is the case with vmstat.
> # cat /proc/zoneinfo | grep cma
>      nr_free_cma  2560
> # cat /proc/vmstat | grep cma
> nr_free_cma 2560

We could add a line to show total cma pages like following and add it all.
# cat /proc/zoneinfo | grep cma
      nr_total_cma XXXX
      nr_free_cma  2560

Yes. each zone can have cma area and it is annoying to add it all.
But IMO it is rare and not difficult.
And I think it'd better that zoneinfo has nr_total_cma line.

I think you already considered my thoughts and choosed /proc/meminfo for a certain reason.
Why is /proc/meminfo better?

Andrew already accepted it. I'm not against your idea. Just curious.

> 
>> I don't know HOTPLUG feature so I'm just asking for sure.
>> Does HOTPLUG not need printing message like this?
>>
> 
> Sorry, I am also not sure what hotplug feature you are referring to.

I mean "memory hotplug" feature.
Forget it ;-)

> 
>> Thanks a lot.
>>
>>
>>>    
>>>        hugetlb_report_meminfo(m);
>>>
>>
>> --
>> To unsubscribe, send a message with 'unsubscribe linux-mm' in
>> the body to majordomo@...ck.org.  For more info on Linux MM,
>> see: http://www.linux-mm.org/ .
>> Don't email: <a href=mailto:"dont@...ck.org">
>> email@...ck.org </a>
>>
> 
> 
--
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