Stack Tracing using Ftrace
Hi, I wrote a module and somehow it is corrupting the thread_info of the process. After some debugging I concluded that its corrupting the kernel stack. Then I came across Ftrace to get the stack trace, which confirmed high stack usage. http://lwn.net/Articles/366796/ I see around 7K in the depth section of first entry in stack_trace. At the same time I run a stap script to get the current stack usage using stack_used function. It comes around 4k. To my understanding the depth section of first entry in stack_trace and value retuned by stack_used should match. Is my understanding correct? Thanks Neependra
System memory increased while process is running is not released back upon process exit
Hi all, I've some application which will do much I/O disk. While this application is running the memory usage of system is continuously increasing. After stopping my process , no memory usage increased. But leaked/increased memory was not released back upon my application exit.This proves that there is no potential memory leaks in my process. Also /proc/PID/status file contents are not changing from start to end. Where is leaked memory was gone even though my application terminates ? I assumed that memory reserved for kernel buffer cache is not releasing back. Correct me if assumption is wrong. So i wanted test Linux Kernel buffer cache memory allocation/release, I take Linux command line utility 'du' Before running this utility , the 'free -m' command output is: total used free sharedbuffers cached Mem: 1004 79924 0 1 21 -/+ buffers/cache: *57*946 Swap: 1992 7 1985 I ran du command on */* directory.It had given the output and exited.Now free command output is: total used free sharedbuffers cached Mem: 1004166837 0 37 21 -/+ buffers/cache:*106*897 Swap: 1992 7 1985 106-57=49M is not released back. The same behavior I observed with my application. I stuck up at this stage to analyze the issue. Is really Linux Kernel is taken the physical memory for buffering and not releasing in back ? If yes , how long it will hold ? Regards, Ravikumar
Re: System memory increased while process is running is not released back upon process exit
Hi! On 19:09 Mon 03 May , ravikumar wrote: ... The same behavior I observed with my application. I stuck up at this stage to analyze the issue. Is really Linux Kernel is taken the physical memory for buffering and not releasing in back ? If yes , how long it will hold ? I have seen this on my server. It is interesting, because according to my understanding only cached files should remain allocated. But they are accounted in the cache column and not in buffers. I think that this is caused by memory sizes so huge compared to the workload that not even cached files can use it up. I guess this is pretty harmless. You could try whether these buffer are freed of you launch a memory hog. If they are not, this might be a bug somewhere. There is a file at /proc/slabinfo which lists which structures this memory is used for. -Michi -- programing a layer 3+4 network protocol for mesh networks see http://michaelblizek.twilightparadox.com -- To unsubscribe from this list: send an email with unsubscribe kernelnewbies to ecar...@nl.linux.org Please read the FAQ at http://kernelnewbies.org/FAQ
Re: Stack Tracing using Ftrace
On Mon, May 3, 2010 at 7:02 PM, Neependra Khare neependra.kh...@gmail.com wrote: Hi, I wrote a module and somehow it is corrupting the thread_info of the process. After some debugging I concluded that its corrupting the kernel stack. Then I came across Ftrace to get the stack trace, which confirmed high stack usage. http://lwn.net/Articles/366796/ I see around 7K in the depth section of first entry in stack_trace. At the same time I run a stap script to get the current stack usage using stack_used function. It comes around 4k. Given that you are eating so much of stack space, you must have lots of local variables or some *big* ones. It might be easy to just open your .ko check the sizes of the variables and compute from there. You can also enable below variables in your .config. CONFIG_DEBUG_STACKOVERFLOW=y CONFIG_DEBUG_STACK_USAGE=y Thanks - Manish To my understanding the depth section of first entry in stack_trace and value retuned by stack_used should match. Is my understanding correct? Thanks Neependra -- Thanks - Manish == [$\*.^ -- I miss being one of them == -- To unsubscribe from this list: send an email with unsubscribe kernelnewbies to ecar...@nl.linux.org Please read the FAQ at http://kernelnewbies.org/FAQ
Shared buffer between user and kernel space
Hi, I need a shared buffer between user and kernel space. I read that one way is to allocated buffer in kernel and then call mmap from the user space. I searched for an example but couldn't find something useful. If you know, could you please send me any links or sample code that does this Thank you... Thanks, Bala
Re: System memory increased while process is running is not released back upon process exit
Around 12 hours back I ran the du command, till now the memory was not re-claimed back Regards, Ravikumar Michael Blizek wrote: Hi! On 19:09 Mon 03 May , ravikumar wrote: ... The same behavior I observed with my application. I stuck up at this stage to analyze the issue. Is really Linux Kernel is taken the physical memory for buffering and not releasing in back ? If yes , how long it will hold ? I have seen this on my server. It is interesting, because according to my understanding only cached files should remain allocated. But they are accounted in the cache column and not in buffers. I think that this is caused by memory sizes so huge compared to the workload that not even cached files can use it up. I guess this is pretty harmless. You could try whether these buffer are freed of you launch a memory hog. If they are not, this might be a bug somewhere. There is a file at /proc/slabinfo which lists which structures this memory is used for. -Michi -- To unsubscribe from this list: send an email with unsubscribe kernelnewbies to ecar...@nl.linux.org Please read the FAQ at http://kernelnewbies.org/FAQ
Re: Stack Tracing using Ftrace
On Tue, May 4, 2010 at 12:01 AM, Steven Rostedt rost...@goodmis.org wrote: If he sees the 7k in the ftrace stack_trace, then it should show where the problems are. The DEBUG_STACKOVERFLOW only tests the stack on interrupts. Yes, I can see where the problem is. Just wondering about the Ftrace and SystemTap output. Thanks for you reply Steve and Manish. Regards, Neependra
