QNX Operating System/Discussion/OSTech/nano_trace.c - waste of buffer space/List of Posts
 
Forum Topic - nano_trace.c - waste of buffer space:
   
Update
Hans-Peter Reichert
10/29/2009 2:15 PM
post41006
nano_trace.c - waste of buffer space   
with my first ring mode kernel trace from a 6.4.1 system I was running in a, at first sight, strange thing.
The trace didn't have the expected size.
With ring mode trace you used to have always a kev size of n-kbufs*16KB

This is now changed, I think because of event data truncation at buf end - at least this was a PR we had filed in the 
past.
But this change was a hard one.
in nano_trace.c you now switch buffers when there are about 300 slots left.

The problem with this is that I used ring mode tracing as the one with the least system impact for limited systems.
As on these systems I also have low memory conditions, the amount of usable kernel buffers is also low - and remember 
each kbuf has to be contigous memory.
So now I am losing 30% of recording time, because buffer space is just not used and I can't just increase num of k-bufs.

what do you think about changeing this threshold to a bit a "smarter" one?

/hp
Hans-Peter Reichert
11/03/2009 2:06 PM
post41251
Re: nano_trace.c - waste of buffer space   
> with my first ring mode kernel trace from a 6.4.1 system I was running in a, 
> at first sight, strange thing.
> The trace didn't have the expected size.
> With ring mode trace you used to have always a kev size of n-kbufs*16KB
> 
> This is now changed, I think because of event data truncation at buf end - at 
> least this was a PR we had filed in the past.
> But this change was a hard one.
> in nano_trace.c you now switch buffers when there are about 300 slots left.
> 
> The problem with this is that I used ring mode tracing as the one with the 
> least system impact for limited systems.
> As on these systems I also have low memory conditions, the amount of usable 
> kernel buffers is also low - and remember each kbuf has to be contigous memory
> .
> So now I am losing 30% of recording time, because buffer space is just not 
> used and I can't just increase num of k-bufs.
> what do you think about changeing this threshold to a bit a "smarter" one?
> 
> /hp


hey ho Mr. Trace (cb) or somebody else
no comments on this?
Colin Burgess(deleted)
11/03/2009 2:13 PM
post41252
Re: nano_trace.c - waste of buffer space   
Sorry HP.

You have a point, but I haven't had a chance to figure out if there
is a "gotcha" lurking in the shadows.

Hans-Peter Reichert wrote:
>> with my first ring mode kernel trace from a 6.4.1 system I was running in a, 
>> at first sight, strange thing.
>> The trace didn't have the expected size.
>> With ring mode trace you used to have always a kev size of n-kbufs*16KB
>>
>> This is now changed, I think because of event data truncation at buf end - at 
>> least this was a PR we had filed in the past.
>> But this change was a hard one.
>> in nano_trace.c you now switch buffers when there are about 300 slots left.
>>
>> The problem with this is that I used ring mode tracing as the one with the 
>> least system impact for limited systems.
>> As on these systems I also have low memory conditions, the amount of usable 
>> kernel buffers is also low - and remember each kbuf has to be contigous memory
>> .
>> So now I am losing 30% of recording time, because buffer space is just not 
>> used and I can't just increase num of k-bufs.
>> what do you think about changeing this threshold to a bit a "smarter" one?
>>
>> /hp
> 
> 
> hey ho Mr. Trace (cb) or somebody else
> no comments on this?
> 
> 
> 
> 
> _______________________________________________
> 
> OSTech
> http://community.qnx.com/sf/go/post41251
> 

-- 
cburgess@qnx.com

Return