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