On Mon, Sep 27, 2010 at 4:47 PM, luca ellero <lroluk@xxxxxxxxx> wrote: > Il 27/09/2010 7.55, Arun KS ha scritto: >> >> On Fri, Sep 24, 2010 at 12:19 AM, luca ellero<lroluk@xxxxxxxxx> wrote: >>> >>> Il 23/09/2010 15.49, Mulyadi Santosa ha scritto: >>>> >>>> Hi... >>>> >>>> On Thu, Sep 23, 2010 at 16:13, Tayade, Nilesh >>>> <Nilesh.Tayade@xxxxxxxxxxxx> wrote: >>>>>> >>>>>> -----Original Message----- >>>>>> From: kernelnewbies-bounce@xxxxxxxxxxxx [mailto:kernelnewbies- >>>>>> bounce@xxxxxxxxxxxx] On Behalf Of Arun KS >>>>>> Sent: Thursday, September 23, 2010 11:30 AM >>>>>> To: kernelnewbies@xxxxxxxxxxxx >>>>>> Subject: memory consumed by kernel >>>>>> >>>>>> Hello There, >>>>>> >>>>>> cat /proc/meminfo will show the memory statistics of the entire >>>>>> system. >>>>>> >>>>>> Is there a way to see the memory consumed by the kernel alone? >>>>> >>>>> I do not have thorough idea. But it seems there is no ready-made tool >>>>> (userspace/kernelspace) to know the complete kernel memory. >>>>> To debug certain memory related issues - we can refer the >>>>> /proc/kallsyms >>>>> (exact place where each symbol is loaded in memory) and /proc/slabinfo >>>>> - >>>>> the slab allocation for different objects. But considering the total >>>>> kernel memory it also includes many other allocations which we do not >>>>> do >>>>> explicitly - like Page tables, or some kind of metadata. >>>> >>>> You need to define the limitation of "consumed by the kernel alone". >>>> is it consumed by kernel but later might be used by user space? >>>> >>>> In my opinion, you can do it the other way around: sum up all user >>>> mode pages. pay attention with shared memory between threads (this is >>>> the greatest hurdle...so far I know none of tools that succesfully >>>> count them without the help of proper kernel patch..which is likely, >>>> outside mainline kernel tree). Consider it N. Then if you substract >>>> Total RAM with N, you get kernel memory consumption >>>> >>>> >>> >>> Hi, >>> you can compile and load this module and look in /var/log/messages. Every >>> "reserved" range above 1MB is likely to be kernel memory. Generally. >>> under >>> 1MB reserved areas belong to BIOS. That is for x86, and recent kernels. >>> For >>> other architectures is more or less the same, ...apart from BIOS :-P >>> >>> You can also grep for "Memory" in dmesg to have the whole picture: >>> >>> Memory: 1024696k/1040320k available (3388k kernel code, 15172k reserved, >>> 1570k data, 384k init, 131016k highmem) >>> >>> regards >>> Luca >>> >>> >>> #include<linux/module.h> >>> #include<linux/moduleparam.h> >>> #include<linux/init.h> >>> >>> #include<linux/kernel.h> >>> #include<linux/slab.h> >>> #include<linux/fs.h> >>> #include<linux/errno.h> >>> #include<linux/types.h> >>> #include<linux/mm.h> >>> #include<linux/kdev_t.h> >>> #include<asm/page.h> >>> #include<linux/cdev.h> >>> #include<linux/device.h> >>> >>> static int simple_init(void) >>> { >>> int i = 0; >>> int temp = 0; >>> int reserved; >>> struct page * pp; >>> >>> while (pfn_valid(i)) { >>> >>> pp = pfn_to_page(i); >>> >>> reserved = PageReserved(pp); >>> >>> if ( ( temp != reserved ) || ( i == 0 ) ) >>> printk("%08x reserved: %s\n", i<< PAGE_SHIFT, >>> reserved? "yes": "no"); >>> >>> temp = reserved; >>> ++i; >>> } >>> >>> return 0; >>> } >>> >>> static void simple_cleanup(void) >>> { >>> } >>> >>> module_init(simple_init); >>> module_exit(simple_cleanup); >> >> Thanks for code. But on my architecture pfn_valid() is returning >> false in first instance itself. >> I am running on arm11 and 2.6.29 kernel. >> >> Arun > > > IIRC ARM architecture doesn't map RAM at physical address 0 (like x86 does). > It maps it at address 0x80000000, 0xC0000000 or some other address, leaving > 0 for flash, ROM or something else. It depends on arch. > So maybe the problem here is that the cycle have to start from a well > defined page frame number and not at 0. The code has to be modified at some > points. > Take this like a hint, at the moment I have no ARM boards at hand so I can't > help you further. Thank you very much. > Regards > Luca > -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
