From: Jeremy Fitzhardinge <jeremy@goop.org>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: Chris Wright <chrisw@sous-sol.org>,
Virtualization Mailing List <virtualization@lists.osdl.org>
Subject: Re: PARAVIRT_SAVE_FLAGS_IRQ_DISABLE composite callsite
Date: Sun, 25 Feb 2007 21:49:49 -0800 [thread overview]
Message-ID: <45E274FD.8090502@goop.org> (raw)
In-Reply-To: <1172457828.13541.39.camel@localhost.localdomain>
Rusty Russell wrote:
> Originally it was just 24 bytes vs 12 bytes, it's probably less now.
> But as I said, it's *really* popular. I don't have the numbers on me,
> but it's almost worth making it the default and implementing cli / sti
> in terms of save & restore 8)
Do you mean statically or dynamically popular. I did a quick look at
the static usage in a PAE kernel:
(site id -> count)
1391 patch sites:
82 -> 126 - pmd_val
29 -> 117 - restore_fl
91 -> 103 - save_fl+irq_disable
57 -> 97 - apic_write
28 -> 90 - save_fl
35 -> 85 - read_msr
...
so you're right, safe_fl+irq_disable is very common in the static
count. Each safe_fl+irq_disable site is 18 bytes vs 10 each for save_fl
and irq_disable on their own, so not fusing them would cost about 200
bytes of kernel text. If we set the clobber for irq_disable to none,
then there would be no need to explicitly save/restore %eax over it.
The upside for removing it would be:
* simpler having a 1:1 relationship between pv_ops functions and
call site types
* better patched code for less work - separate callsites can be
patched by the generic patcher, but the combined callsite type
will always need special casing
Well, that's it really, simpler. I just had a bug as a result of its
special type, and from the comments in vmi.c it doesn't seem too popular
over there either.
J
next prev parent reply other threads:[~2007-02-26 5:49 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-25 9:40 PARAVIRT_SAVE_FLAGS_IRQ_DISABLE composite callsite Jeremy Fitzhardinge
2007-02-25 22:07 ` Rusty Russell
2007-02-26 0:51 ` Jeremy Fitzhardinge
2007-02-26 2:43 ` Rusty Russell
2007-02-26 5:49 ` Jeremy Fitzhardinge [this message]
2007-02-26 23:28 ` Rusty Russell
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=45E274FD.8090502@goop.org \
--to=jeremy@goop.org \
--cc=chrisw@sous-sol.org \
--cc=rusty@rustcorp.com.au \
--cc=virtualization@lists.osdl.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 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).