From: "Alan D. Brunelle" <Alan.Brunelle@hp.com>
To: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Cc: Jens Axboe <jens.axboe@oracle.com>,
linux-kernel@vger.kernel.org,
btrace <linux-btrace@vger.kernel.org>
Subject: Re: Linux Kernel Markers - performance characterization with large
Date: Tue, 02 Oct 2007 17:51:22 +0000 [thread overview]
Message-ID: <4702851A.1050100@hp.com> (raw)
In-Reply-To: <20071002124803.GA23425@Krystal>
Mathieu Desnoyers wrote:
>> remember that we have seen and discussed something like this before,
>> it's still a puzzle to me...
>>
>>
> I do wonder about that performance _increase_ with blktrace enabled. I
>
> Interesting question indeed.
>
> In those tests, when blktrace is running, are the relay buffers only
> written to or they are also read ?
>
blktrace (the utility) was running too - so the relay buffere /were/
being read and stored out to disk elsewhere.
> Running the tests without consuming the buffers (in overwrite mode)
> would tell us more about the nature of the disturbance causing the
> performance increase.
>
I'd have to write a utility to enable the traces, but then not read. Let
me think about that.
> Also, a kernel trace could help us understand more thoroughly what is
> happening there.. is it caused by the scheduler ? memory allocation ?
> data cache alignment ?
>
Yep - when I get some time, I'll look into that. [Clearly not a gating
issue for marker support...]
> I would suggest that you try aligning the block layer data structures
> accessed by blktrace on L2 cacheline size and compare the results (when
> blktrace is disabled).
>
Again, when I get some time! :-)
Alan
WARNING: multiple messages have this Message-ID (diff)
From: "Alan D. Brunelle" <Alan.Brunelle@hp.com>
To: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Cc: Jens Axboe <jens.axboe@oracle.com>,
linux-kernel@vger.kernel.org,
btrace <linux-btrace@vger.kernel.org>
Subject: Re: Linux Kernel Markers - performance characterization with large IO load on large-ish system
Date: Tue, 02 Oct 2007 13:51:22 -0400 [thread overview]
Message-ID: <4702851A.1050100@hp.com> (raw)
In-Reply-To: <20071002124803.GA23425@Krystal>
Mathieu Desnoyers wrote:
>> remember that we have seen and discussed something like this before,
>> it's still a puzzle to me...
>>
>>
> I do wonder about that performance _increase_ with blktrace enabled. I
>
> Interesting question indeed.
>
> In those tests, when blktrace is running, are the relay buffers only
> written to or they are also read ?
>
blktrace (the utility) was running too - so the relay buffere /were/
being read and stored out to disk elsewhere.
> Running the tests without consuming the buffers (in overwrite mode)
> would tell us more about the nature of the disturbance causing the
> performance increase.
>
I'd have to write a utility to enable the traces, but then not read. Let
me think about that.
> Also, a kernel trace could help us understand more thoroughly what is
> happening there.. is it caused by the scheduler ? memory allocation ?
> data cache alignment ?
>
Yep - when I get some time, I'll look into that. [Clearly not a gating
issue for marker support...]
> I would suggest that you try aligning the block layer data structures
> accessed by blktrace on L2 cacheline size and compare the results (when
> blktrace is disabled).
>
Again, when I get some time! :-)
Alan
next prev parent reply other threads:[~2007-10-02 17:51 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-25 14:58 Linux Kernel Markers - performance characterization with large Alan D. Brunelle
2007-09-25 14:58 ` Linux Kernel Markers - performance characterization with large IO load on large-ish system Alan D. Brunelle
2007-09-25 17:13 ` Mathieu Desnoyers
2007-09-25 17:13 ` Mathieu Desnoyers
2007-09-26 15:28 ` Linux Kernel Markers - performance characterization with large Alan D. Brunelle
2007-09-26 15:28 ` Linux Kernel Markers - performance characterization with large IO load on large-ish system Alan D. Brunelle
2007-10-02 12:21 ` Linux Kernel Markers - performance characterization with large Jens Axboe
2007-10-02 12:21 ` Linux Kernel Markers - performance characterization with large IO load on large-ish system Jens Axboe
2007-10-02 12:48 ` Mathieu Desnoyers
2007-10-02 12:48 ` Mathieu Desnoyers
2007-10-02 17:51 ` Alan D. Brunelle [this message]
2007-10-02 17:51 ` Alan D. Brunelle
2007-10-07 19:32 ` Linux Kernel Markers - performance characterization with large Ingo Molnar
2007-10-07 19:32 ` Linux Kernel Markers - performance characterization with large IO load on large-ish system Ingo Molnar
2007-10-07 22:10 ` Linux Kernel Markers - performance characterization with large Joshua Root
2007-10-07 22:10 ` Linux Kernel Markers - performance characterization with large IO load on large-ish system Joshua Root
2007-10-09 17:31 ` Mathieu Desnoyers
2007-10-09 17:31 ` Mathieu Desnoyers
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=4702851A.1050100@hp.com \
--to=alan.brunelle@hp.com \
--cc=jens.axboe@oracle.com \
--cc=linux-btrace@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@polymtl.ca \
/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.