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? > it is help when enable trace for a long period. Help exactly how? What is saved exactly, and what about cpu usage? > 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
