Lets make wifi fast again!
 help / color / mirror / Atom feed
From: John Yates <john@yates-sheets.org>
To: "Toke Høiland-Jørgensen" <toke@redhat.com>
Cc: Johannes Berg <johannes@sipsolutions.net>,
	 linux-wireless <linux-wireless@vger.kernel.org>,
	Kan Yan <kyan@google.com>,
	 Make-Wifi-fast <make-wifi-fast@lists.bufferbloat.net>,
	Yibo Zhao <yiboz@codeaurora.org>,
	 Rajkumar Manoharan <rmanohar@codeaurora.org>,
	Felix Fietkau <nbd@nbd.name>
Subject: Re: [Make-wifi-fast] [PATCH v5] mac80211: Switch to a virtual time-based airtime scheduler
Date: Mon, 6 Jan 2020 17:19:58 -0500	[thread overview]
Message-ID: <CAJnXXogQCKQSLT+8_NnEfFd7MLc0=YxShvb4hY2Y+BDJjybQTg@mail.gmail.com> (raw)
In-Reply-To: <87mub0k2cd.fsf@toke.dk>

On Mon, Jan 6, 2020 at 10:54 AM Toke Høiland-Jørgensen <toke@redhat.com> wrote:
> Yeah, we'd be doing the accumulation in 64bit values in any case; we're
> talking about mainly multiplication here (the whole point of the
> reciprocal stuff is to get the division out of the fast path). So how
> big of an impact is one (or two) extra 64-bit multiplications going to
> have on a 32bit platform?

Top line: usually replacing 64 bit divide with multiply is a massive win.

Many platforms make (32 bits * 32 bits) -> 64 bits quite cheap:
- x86 has this as a single instruction: eax * edx -> eax:edx
- arm has much the same, plus a variant that tacks ona  64 bit accumulation!
- mips leaves the 64 bit product in a dedicated register; retrieval
requires 2 instructions
- ppc, being more "RISCy", has two instruction: mullo and mulhi
(performs multiply twice!)

Best case is when the compiler can recognize a 64 bit multiply as really

  widen_32_to_64(left) x widen_32_to_64(right) -> 64_bit_product

In such a case only one of the above multiply cases is necessary.  Otherwise
one tends to get multiple partial products and double width additions.  Still,
better than nearly any flavor of 64 bit divide.

/john

  reply	other threads:[~2020-01-06 22:20 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-22 17:24 Toke Høiland-Jørgensen
2020-01-02 14:13 ` Johannes Berg
2020-01-06 15:20   ` Toke Høiland-Jørgensen
2020-01-06 15:47     ` John Yates
2020-01-06 15:54       ` Toke Høiland-Jørgensen
2020-01-06 22:19         ` John Yates [this message]
2020-01-07 10:43           ` Toke Høiland-Jørgensen

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

  List information: https://lists.bufferbloat.net/postorius/lists/make-wifi-fast.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAJnXXogQCKQSLT+8_NnEfFd7MLc0=YxShvb4hY2Y+BDJjybQTg@mail.gmail.com' \
    --to=john@yates-sheets.org \
    --cc=johannes@sipsolutions.net \
    --cc=kyan@google.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=make-wifi-fast@lists.bufferbloat.net \
    --cc=nbd@nbd.name \
    --cc=rmanohar@codeaurora.org \
    --cc=toke@redhat.com \
    --cc=yiboz@codeaurora.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