>> >> I tried number 1 using --read-timer 0, but "lttng stop" hanged at >> >> "Waiting for data availability", producing lots of dots... >> > >> > As I said, we'd need to implement RING_BUFFER_WAKEUP_BY_WRITER when >> > read-timer is set to 0. It's not implemented currently. >> > >> >> >> >> Would it be possible to let some other (not using nohz mode) CPU to >> >> flush the buffers? >> > >> > I guess that would be option 3) : >> > >> > Another option would be to let a single thread in the consumer handle >> > the read-timer for all streams of the channel, like we do for UST. >> >> Ehm, well, you did say something about implement... Sorry for missing that. >> >> I guess now the question is which option that gives best >> characteristics for least amount of work... Without knowing the design >> of lttng-module, I'd believe that simply having the timer on another >> CPU should be a good candidate. Is there anything to watch out for >> with this solution? >> >> Are there any documents describing lttng-module design, or is it "join >> the force, use the source"? I've seen some high-level description >> showing how tools/libs/modules fit together, but I haven't found >> anything that describes how lttng-modules is designed. > > Papers on the ring buffer design exist, but not on lttng-modules per se. > > I think the best solution in the shortest amount of time would be (2): > using deferrable timers. It's just flags to pass to timer creation.
Doesn't that require that the system is idle from time to time? My application will occupy 100% CPU until finished, and expects there are no ticks during that time. /Mats _______________________________________________ lttng-dev mailing list [email protected] http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
