All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Alex Bennée" <alex.bennee@linaro.org>
To: Vasilev Oleg <vasilev.oleg@huawei.com>
Cc: "peter.maydell@linaro.org" <peter.maydell@linaro.org>,
	Konobeev Vladimir <konobeev.vladimir@huawei.com>,
	Plotnik Nikolay <plotnik.nikolay@huawei.com>,
	Richard Henderson <richard.henderson@linaro.org>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Andrey Shinkevich <andrey.shinkevich@huawei.com>,
	"Emilio G. Cota" <cota@braap.org>,
	"qemu-arm@nongnu.org" <qemu-arm@nongnu.org>,
	"Chengen (William, FixNet)" <chengen@huawei.com>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: Suggestions for TCG performance improvements
Date: Mon, 06 Dec 2021 21:09:38 +0000	[thread overview]
Message-ID: <87a6hdmo8x.fsf@linaro.org> (raw)
In-Reply-To: <35631f7cceb141879aa7475ccaf81acb@huawei.com>


Vasilev Oleg <vasilev.oleg@huawei.com> writes:

> On 12/3/2021 8:32 PM, Alex Bennée wrote:
>> Vasilev Oleg <vasilev.oleg@huawei.com> writes:
>>
>>> On 12/2/2021 7:02 PM, Alex Bennée wrote:
>>>
>>>> Vasilev Oleg <vasilev.oleg@huawei.com> writes:
> ...skipped...
>>>> I did ponder a debug mode which would keep the last N tables dropped by
>>>> tlb_mmu_resize_locked and then measure the differences in the entries
>>>> before submitting the free to an rcu tasks.
>>>>> The mentioned paper[4] also describes other possible improvements.
>>>>> Some of those are already implemented (such as victim TLB and dynamic
>>>>> size for TLB), but others are not (e.g. TLB lookup uninlining and
>>>>> set-associative TLB layer). Do you think those improvements
>>>>> worth trying?
>>>> Anything is worth trying but you would need hard numbers. Also its all
>>>> too easy to target micro benchmarks which might not show much difference
>>>> in real world use. 
>>> The  mentioned paper presents some benchmarking, e. g. linux kernel
>>> compilation and some other stuff. Do you think those shouldn't be
>>> trusted?
>> No they are good. To be honest it's the context switches that get you.
>> Look at "info jit" between a normal distro and a initramfs shell. Places
>> where the kernel is switching between multiple maps means a churn of TLB
>> data.
>>
>> See my other post with a match of "msr ttrb"
> Sorry, couldn't find what you are referring to. Could you, please, share
> a link?

It was an enhancement to the libinsns.so plugin to gauge how often
certain instructions are run:

  Subject: [RFC PATCH  0/2] insn plugin tweaks for measuring frequency
  Date: Fri,  3 Dec 2021 14:44:19 +0000
  Message-Id: <20211203144421.1445232-1-alex.bennee@linaro.org>

I think the msr ttrb[10]_el1 is a key instruction because that triggers
a flush if the ASID changes. On my initramfs setup with a simple login
shell that doesn't happen, on a full distro there is context switching
all the time which causes extra flushes.

-- 
Alex Bennée

WARNING: multiple messages have this Message-ID (diff)
From: "Alex Bennée" <alex.bennee@linaro.org>
To: Vasilev Oleg <vasilev.oleg@huawei.com>
Cc: "peter.maydell@linaro.org" <peter.maydell@linaro.org>,
	Konobeev Vladimir <konobeev.vladimir@huawei.com>,
	"Chengen \(William, FixNet\)" <chengen@huawei.com>,
	Richard Henderson <richard.henderson@linaro.org>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	Andrey Shinkevich <andrey.shinkevich@huawei.com>,
	"Emilio G. Cota" <cota@braap.org>,
	Plotnik Nikolay <plotnik.nikolay@huawei.com>,
	Paolo Bonzini <pbonzini@redhat.com>,
	"qemu-arm@nongnu.org" <qemu-arm@nongnu.org>
Subject: Re: Suggestions for TCG performance improvements
Date: Mon, 06 Dec 2021 21:09:38 +0000	[thread overview]
Message-ID: <87a6hdmo8x.fsf@linaro.org> (raw)
In-Reply-To: <35631f7cceb141879aa7475ccaf81acb@huawei.com>


Vasilev Oleg <vasilev.oleg@huawei.com> writes:

> On 12/3/2021 8:32 PM, Alex Bennée wrote:
>> Vasilev Oleg <vasilev.oleg@huawei.com> writes:
>>
>>> On 12/2/2021 7:02 PM, Alex Bennée wrote:
>>>
>>>> Vasilev Oleg <vasilev.oleg@huawei.com> writes:
> ...skipped...
>>>> I did ponder a debug mode which would keep the last N tables dropped by
>>>> tlb_mmu_resize_locked and then measure the differences in the entries
>>>> before submitting the free to an rcu tasks.
>>>>> The mentioned paper[4] also describes other possible improvements.
>>>>> Some of those are already implemented (such as victim TLB and dynamic
>>>>> size for TLB), but others are not (e.g. TLB lookup uninlining and
>>>>> set-associative TLB layer). Do you think those improvements
>>>>> worth trying?
>>>> Anything is worth trying but you would need hard numbers. Also its all
>>>> too easy to target micro benchmarks which might not show much difference
>>>> in real world use. 
>>> The  mentioned paper presents some benchmarking, e. g. linux kernel
>>> compilation and some other stuff. Do you think those shouldn't be
>>> trusted?
>> No they are good. To be honest it's the context switches that get you.
>> Look at "info jit" between a normal distro and a initramfs shell. Places
>> where the kernel is switching between multiple maps means a churn of TLB
>> data.
>>
>> See my other post with a match of "msr ttrb"
> Sorry, couldn't find what you are referring to. Could you, please, share
> a link?

It was an enhancement to the libinsns.so plugin to gauge how often
certain instructions are run:

  Subject: [RFC PATCH  0/2] insn plugin tweaks for measuring frequency
  Date: Fri,  3 Dec 2021 14:44:19 +0000
  Message-Id: <20211203144421.1445232-1-alex.bennee@linaro.org>

I think the msr ttrb[10]_el1 is a key instruction because that triggers
a flush if the ASID changes. On my initramfs setup with a simple login
shell that doesn't happen, on a full distro there is context switching
all the time which causes extra flushes.

-- 
Alex Bennée


  reply	other threads:[~2021-12-06 21:12 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-02  9:47 Suggestions for TCG performance improvements Vasilev Oleg
2021-12-02 15:31 ` Alex Bennée
2021-12-02 15:31   ` Alex Bennée
2021-12-03 16:21   ` Vasilev Oleg
2021-12-03 16:21     ` Vasilev Oleg via
2021-12-03 17:27     ` Alex Bennée
2021-12-03 17:27       ` Alex Bennée
2021-12-06 19:40       ` Vasilev Oleg
2021-12-06 19:40         ` Vasilev Oleg via
2021-12-06 21:09         ` Alex Bennée [this message]
2021-12-06 21:09           ` Alex Bennée
2021-12-03  5:21 ` Emilio Cota
2021-12-03  5:21   ` Emilio Cota
2021-12-03  6:30   ` Richard Henderson
2021-12-03  6:30     ` Richard Henderson

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=87a6hdmo8x.fsf@linaro.org \
    --to=alex.bennee@linaro.org \
    --cc=andrey.shinkevich@huawei.com \
    --cc=chengen@huawei.com \
    --cc=cota@braap.org \
    --cc=konobeev.vladimir@huawei.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=plotnik.nikolay@huawei.com \
    --cc=qemu-arm@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=richard.henderson@linaro.org \
    --cc=vasilev.oleg@huawei.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 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.