Re: [PATCH v2 00/11] usb: gadget: reduce usb gadget trace event buffer usage

[Linyu Yuan <quic_linyyuan@quicinc.com>]

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