From: Julien Grall <julien.grall@arm.com>
To: Andrii Anisov <andrii.anisov@gmail.com>,
Andre Przywara <andre.przywara@arm.com>
Cc: xen-devel@lists.xenproject.org,
Stefano Stabellini <sstabellini@kernel.org>,
Andrii Anisov <andrii_anisov@epam.com>
Subject: Re: [RFC 10/16] gic:vgic:gic-vgic: introduce non-atomic bitops
Date: Mon, 3 Dec 2018 12:58:26 +0000 [thread overview]
Message-ID: <0225bd51-824f-2f98-afa5-c4f5e9456885@arm.com> (raw)
In-Reply-To: <f71bead8-4450-7f51-06d4-f4f6021df8d6@gmail.com>
Hi Andrii,
On 03/12/2018 12:33, Andrii Anisov wrote:
> On 29.11.18 14:14, Andre Przywara wrote:
>> Nah, please don't do this.
> Sorry for making you crying looking at this code.
> It's terrible, I know. It's rather an idea.
>
>> Can you show that atomic bit ops are a
>> problem? They shouldn't be expensive unless contended, also pretty
>> lightweight on small systems (single cluster).
> Yep, but still it is a call to a function of 10 operations instead of one `orr`
> for set_bit(). Taking in account a heavy usage of bitops in the old vgic code,
> this should benefit latency.
That's micro optimizing Xen... there are better (and less risky) place to look
for optimization.
Knowing how fragile the locking is on the old vGIC, the risk of micro-optimizing
is not worth it. If you can provide number that shows you can improve
performance by more than 10% in common case with this patch only, then I will
reconsider my position.
Cheers,
--
Julien Grall
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
next prev parent reply other threads:[~2018-12-03 12:59 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1543440731-21947-1-git-send-email-andrii.anisov@gmail.com>
2018-11-28 21:31 ` [RFC 01/16] xen/arm: Re-enable interrupt later in the trap path Andrii Anisov
2018-11-28 22:00 ` Julien Grall
2019-07-30 17:34 ` [Xen-devel] " Andrii Anisov
2019-07-30 20:46 ` Julien Grall
2018-11-28 21:31 ` [RFC 02/16] hack: drop GIC v3 support Andrii Anisov
2018-11-29 12:08 ` Andre Przywara
2018-11-28 21:31 ` [RFC 03/16] vgic: move pause_flags check out of vgic spinlock Andrii Anisov
2018-11-28 22:02 ` Julien Grall
2018-11-28 21:31 ` [RFC 04/16] vgic: move irq_to_pending out of lock Andrii Anisov
2018-11-29 11:07 ` Julien Grall
2018-11-28 21:32 ` [RFC 05/16] gic-vgic: Drop an excessive clear_lrs Andrii Anisov
2018-12-11 14:33 ` Julien Grall
2018-12-12 11:01 ` Andrii Anisov
2018-12-12 11:55 ` Julien Grall
2018-11-28 21:32 ` [RFC 06/16] gic: drop interrupts enabling on interrupts processing Andrii Anisov
2018-11-28 22:06 ` Julien Grall
2018-12-12 12:10 ` Julien Grall
2018-11-28 21:32 ` [RFC 07/16] gic-vgic:vgic: do not keep disabled IRQs in any of queues Andrii Anisov
2018-11-28 21:32 ` [RFC 08/16] gic: separate ppi processing Andrii Anisov
2018-12-12 12:37 ` Andrii Anisov
2018-12-12 12:46 ` Julien Grall
2018-12-12 12:52 ` Andrii Anisov
2018-12-12 13:46 ` Julien Grall
2018-11-28 21:32 ` [RFC 09/16] gic-vgic:vgic: avoid excessive conversions Andrii Anisov
2018-11-29 10:23 ` Julien Grall
2018-11-28 21:32 ` [RFC 10/16] gic:vgic:gic-vgic: introduce non-atomic bitops Andrii Anisov
2018-11-29 12:14 ` Andre Przywara
2018-11-29 16:07 ` Julien Grall
2018-12-03 12:33 ` Andrii Anisov
2018-12-03 12:58 ` Julien Grall [this message]
2018-12-03 13:05 ` Andrii Anisov
2018-12-03 13:08 ` Julien Grall
2018-12-03 16:37 ` Andre Przywara
2018-11-28 21:32 ` [RFC 11/16] irq: skip action avalability check for guest's IRQ Andrii Anisov
2018-12-11 14:48 ` Julien Grall
2018-12-12 11:30 ` Andrii Anisov
2018-12-12 11:59 ` Julien Grall
2018-12-12 13:51 ` Andrii Anisov
2018-12-12 14:49 ` Julien Grall
2018-12-12 14:58 ` Andrii Anisov
2018-12-12 15:08 ` Julien Grall
2018-12-12 15:57 ` Andrii Anisov
2018-11-28 21:32 ` [RFC 12/16] gic-v2: Write HCR only on change Andrii Anisov
2018-11-29 16:36 ` Julien Grall
2018-11-28 21:32 ` [RFC 13/16] gic-vgic: skip irqs locking Andrii Anisov
2018-12-12 12:07 ` Julien Grall
2018-12-12 12:35 ` Andrii Anisov
2018-12-12 12:44 ` Julien Grall
2018-12-12 12:47 ` Andrii Anisov
2018-11-28 21:32 ` [RFC 14/16] hack: arm/domain: simplify context restore from idle vcpu Andrii Anisov
2018-11-29 15:53 ` Julien Grall
2018-11-29 16:00 ` Wei Liu
2018-11-28 21:32 ` [RFC 15/16] hack: move gicv2 LRs reads and writes out of spinlocks Andrii Anisov
2018-11-28 21:58 ` Julien Grall
2018-11-28 21:32 ` [RFC 16/16] gic: vgic: align frequently accessed data by cache line size Andrii Anisov
2018-11-29 16:24 ` Julien Grall
2018-11-29 7:40 ` [RFC 00/16] Old GIC (gic-vgic) optimizations for GICV2 Andrii Anisov
2018-11-29 11:00 ` Julien Grall
2018-11-29 12:07 ` Andre Przywara
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=0225bd51-824f-2f98-afa5-c4f5e9456885@arm.com \
--to=julien.grall@arm.com \
--cc=andre.przywara@arm.com \
--cc=andrii.anisov@gmail.com \
--cc=andrii_anisov@epam.com \
--cc=sstabellini@kernel.org \
--cc=xen-devel@lists.xenproject.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.