linux-trace-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: John Keeping <john@metanate.com>
Cc: linux-trace-devel@vger.kernel.org, linux-kernel@vger.kernel.org,
	Ingo Molnar <mingo@redhat.com>
Subject: Re: [PATCH/RFC] tracing: make trace_marker{,_raw} stream-like
Date: Thu, 9 Sep 2021 08:35:29 -0400	[thread overview]
Message-ID: <20210909083529.34ae09da@gandalf.local.home> (raw)
In-Reply-To: <20210909115734.3818711-1-john@metanate.com>

On Thu,  9 Sep 2021 12:57:34 +0100
John Keeping <john@metanate.com> wrote:

> The tracing marker files are write-only streams with no meaningful
> concept of file position.  Using stream_open() to mark them as
> stream-link indicates this and has the added advantage that a single
> file descriptor can now be used from multiple threads without contention
> thanks to clearing FMODE_ATOMIC_POS.
> 
> Note that this has the potential to break existing userspace by since
> both lseek(2) and pwrite(2) will now return ESPIPE when previously lseek
> would have updated the stored offset and pwrite would have appended to
> the trace.  A survey of libtracefs and several other projects found to
> use trace_marker(_raw) [1][2][3] suggests that everyone limits
> themselves to calling write(2) and close(2) on these file descriptors so
> there is a good chance this will go unnoticed and the benefits of
> reduced overhead and lock contention seem worth the risk.
> 
> [1] https://github.com/google/perfetto
> [2] https://github.com/intel/media-driver/
> [3] https://w1.fi/cgit/hostap/
> 
> Signed-off-by: John Keeping <john@metanate.com>
> ---
> I'm marking this as RFC because it breaks the Prime Directive of Linux
> development, as explained above.  But I'm hoping this is one of the

The "Prime Directive of Linux development" is the tree falling in the
forest approach. If you break user space API but there's no user space
application around to notice the break, did you really break it? The answer
is "No".

> cases where we get away with it because this is a huge improvement for
> multi-threaded programs when doing the simple thing of opening a single
> trace_marker FD at startup and just writing to it from any thread.

I like the idea too.

> 
> After writing this, I realised that an alternative solution to my
> original problem would have been to use pwrite instead of write!  But I
> still think fixing this at the source would be better.

I'm fine with adding this. But I'm going to add it after the merge window
for the next release (5.16).

If someone complains that it broke their application, we may need to revert
it, but I doubt that will happen.

-- Steve

  reply	other threads:[~2021-09-09 13:21 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-09 11:57 [PATCH/RFC] tracing: make trace_marker{,_raw} stream-like John Keeping
2021-09-09 12:35 ` Steven Rostedt [this message]
2021-12-07 10:31   ` John Keeping
2021-12-07 14:03     ` Steven Rostedt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210909083529.34ae09da@gandalf.local.home \
    --to=rostedt@goodmis.org \
    --cc=john@metanate.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-trace-devel@vger.kernel.org \
    --cc=mingo@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).