All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <axboe@kernel.dk>
To: Jan Kara <jack@suse.cz>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: BLK_TN_PROCESS events not delivered for all devices
Date: Tue, 17 Sep 2013 12:23:33 -0600	[thread overview]
Message-ID: <52389E25.5010605@kernel.dk> (raw)
In-Reply-To: <20130917171028.GB16938@quack.suse.cz>

On 09/17/2013 11:10 AM, Jan Kara wrote:
> On Tue 17-09-13 08:29:07, Jens Axboe wrote:
>> On 09/16/2013 03:23 AM, Jan Kara wrote:
>>>   Hi,
>>>
>>>   I've been looking into a problem where BLK_TN_PROCESS events are not
>>> delivered to all devices which are being traced. This results in process
>>> name being (null) when trace for a single device is parsed.
>>>
>>> The reason for this problem is that trace_note_tsk() is called only if
>>> tsk->btrace_seq != blktrace_seq and it updates tsk->btrace_seq to
>>> blktrace_seq. Thus after a trace for another device is started
>>> BLK_TN_PROCESS event is sent only on behalf of the first device with which
>>> the task interacts. That isn't necessarily the new device thus traces for
>>> some devices accumulate several BLK_TN_PROCESS events for one task while
>>> other have none. Is this a known problem and is this intended to work
>>> better?
>>>
>>> I was thinking how to fix that for a while and it doesn't seem to be
>>> possible without tracking with each block trace which tasks it has been
>>> notified about. And that is relatively expensive...
>>
>> It is unfortunately a known issue... I have not come up with a good way
>> to fix it either, while keeping it cheap. So if you think of something,
>> do let me know.
>   Hum... How about linking all running block traces (struct blk_trace) in a
> linked list and sending BLK_TN_PROCESS to all the traces? Sure we will be
> spamming with BLK_TN_PROCESS a bit but starting a trace isn't such a common
> thing so it shouldn't be too bad. What do you think?

That might be good enough. I'm not worried about start/stop type
expenses, those things generally don't matter. And the list wont add any
fast path overhead when tracing.

-- 
Jens Axboe


  reply	other threads:[~2013-09-17 18:23 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-16  9:23 BLK_TN_PROCESS events not delivered for all devices Jan Kara
2013-09-17 14:29 ` Jens Axboe
2013-09-17 17:10   ` Jan Kara
2013-09-17 18:23     ` Jens Axboe [this message]
2013-09-17 20:31       ` Jan Kara

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=52389E25.5010605@kernel.dk \
    --to=axboe@kernel.dk \
    --cc=jack@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.