Neependra Khare | 3 May 15:32 2010
Picon

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




ravikumar | 3 May 15:39 2010
Picon

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     shared    buffers     cached
Mem:          1004         79        924          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     shared    buffers     cached
Mem:          1004        166        837          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
Michael Blizek | 3 May 18:11 2010

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 ecartis <at> nl.linux.org
Please read the FAQ at http://kernelnewbies.org/FAQ

Manish Katiyar | 3 May 18:45 2010
Picon

Re: Stack Tracing using Ftrace

On Mon, May 3, 2010 at 7:02 PM, Neependra Khare
<neependra.khare <at> 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 ecartis <at> nl.linux.org
Please read the FAQ at http://kernelnewbies.org/FAQ

Balachandar | 4 May 04:17 2010
Picon

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
ravikumar | 4 May 06:41 2010
Picon

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 ecartis <at> nl.linux.org
Please read the FAQ at http://kernelnewbies.org/FAQ

Neependra Khare | 4 May 06:51 2010
Picon

Re: Stack Tracing using Ftrace


On Tue, May 4, 2010 at 12:01 AM, Steven Rostedt <rostedt <at> 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

ravikumar | 4 May 07:48 2010
Picon

Re: System memory increased while process is running is not released back upon process exit


Could somebody please provide your thoughts or inputs on below mentioned 
issue.

Regards,
Ravikumar

ravikumar wrote:
> 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     shared    buffers     cached
> Mem:          1004         79        924          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     shared    buffers     cached
> Mem:          1004        166        837          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

--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis <at> nl.linux.org
Please read the FAQ at http://kernelnewbies.org/FAQ

Arun KS | 4 May 08:24 2010
Picon

Re: Shared buffer between user and kernel space

check this
On Tue, May 4, 2010 at 11:17 AM, Balachandar <bala1486 <at> gmail.com> wrote:
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

Joel Fernandes | 4 May 09:11 2010
Picon

Fwd: System memory increased while process is running is not released back upon process exit

Just forwarding to the list

---------- Forwarded message ----------
From: Joel Fernandes <agnel.joel <at> gmail.com>
Date: Tue, May 4, 2010 at 12:40 PM
Subject: Re: System memory increased while process is running is not
released back upon process exit
To: ravikumar <ravikumar.vallabhu <at> gmail.com>

Hi Ravikumar,

>>
>> 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.

Your assumptions is correct.

>> 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 ?

It will hold it as long as it can, its only we're low on memory that
memory is freed, There is a way to release this memory (but note that
dirty pages cannot be freed before they are written back to their
backing devices)

from Documentation/sysctl/vm.txt
==============================================================

drop_caches

Writing to this will cause the kernel to drop clean caches, dentries and
inodes from memory, causing that memory to become free.

To free pagecache:
       echo 1 > /proc/sys/vm/drop_caches
To free dentries and inodes:
       echo 2 > /proc/sys/vm/drop_caches
To free pagecache, dentries and inodes:
       echo 3 > /proc/sys/vm/drop_caches

As this is a non-destructive operation and dirty objects are not freeable, the
user should run `sync' first.

==============================================================

HTH
-Joel

--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis <at> nl.linux.org
Please read the FAQ at http://kernelnewbies.org/FAQ


Gmane