On 9/11/2023 9:48 PM, Greg Kroah-Hartman wrote:
On Mon, Sep 11, 2023 at 09:44:21PM +0800, Linyu Yuan wrote:
On 9/11/2023 9:32 PM, Greg Kroah-Hartman wrote:
On Mon, Sep 11, 2023 at 07:24:35PM +0800, Linyu Yuan wrote:
some trace event use an interger to to save a bit field info of gadget,
also some trace save endpoint name in string forat, it all can be
chagned to other way at trace event store phase.
bit field can be replace with a union interger member which include
multiple bit fields.
ep name stringe can be replace to a interger which contaion number
and dir info.
Ok, but how much memory did you actually save here? Is the memory saved
only if tracing is enbaled, or it is always? Is there a speed penality
for these changes or is it the same?
yes, it is save trace ring buffer only when tracing enabled, as save less
data, speed is higher.
Are you sure? You now have to parse the data, so how is it faster?
i mean when enable tracing and save less entry data to ring buffer, it
will faster.
i didn't pay attention to runtime parse data, as i think ring buffer is
important,
in most case, after issue happen, we can write tool to parse it from dump,
there is no runtime parse.
it is help when enable trace for a long period.
Help exactly how? What is saved exactly, and what about cpu usage?
consider trace ring buffer is a default size, if every trace entry
smaller, it will save
more entries.
for a single trace entry, take struct usb_gadget as example, at worst case,
it save (19 dword - 1 dword) / 19dword = 94% buffer.
for ep name, it only need 4 bytes/ (4bytes + 9bytes ) = 30%.
And this buffer size reduction shows up where? Are you trading space
for CPU time? Somehow you are ending up with the same information in
userspace, so where are the tradeoffs?
thanks,
greg k-h
