public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Andy Lutomirski <luto@amacapital.net>
To: Florian Weimer <fw@deneb.enyo.de>
Cc: Andy Lutomirski <luto@kernel.org>,
	"H. J. Lu" <hjl.tools@gmail.com>, X86 ML <x86@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	"Bae, Chang Seok" <chang.seok.bae@intel.com>,
	Carlos O'Donell <carlos@redhat.com>,
	Rich Felker <dalias@libc.org>,
	libc-alpha <libc-alpha@sourceware.org>
Subject: Re: Why does glibc use AVX-512?
Date: Fri, 26 Mar 2021 14:21:05 -0700	[thread overview]
Message-ID: <C624A1B5-45EE-491C-B43B-5605D48273E9@amacapital.net> (raw)
In-Reply-To: <87pmzlboxj.fsf@mid.deneb.enyo.de>



> On Mar 26, 2021, at 2:11 PM, Florian Weimer <fw@deneb.enyo.de> wrote:
> 
> * Andy Lutomirski:
> 
>>> On Fri, Mar 26, 2021 at 1:35 PM Florian Weimer <fw@deneb.enyo.de> wrote:
>>> 
>>> I mean the immense slowdown you get if you use %xmm registers after
> their %ymm counterparts (doesn't have to be %zmm, that issue is
> present starting with AVX) and you have not issued VZEROALL or
> VZEROUPPER between the two uses.

It turns out that it’s not necessary to access the registers in question to trigger this behavior. You just need to make the CPU think it should penalize you. For example, LDMXCSR appears to be a legacy SSE insn for this purpose, and VLDMXCSR is an AVX insn for this purpose. I wouldn’t trust that using ymm9 would avoid the penalty just because common sense says it should.

>> What kind of system has that problem?
> 
> It's a standard laptop after a suspend/resume cycle.  It's either a
> kernel or firmware bug.

What kernel version?  I think fixing the kernel makes more sense than fixing glibc.


  reply	other threads:[~2021-03-26 21:21 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-26  4:38 Andy Lutomirski
2021-03-26 10:06 ` Borislav Petkov
2021-03-26 18:17   ` Andy Lutomirski
2021-03-26 12:12 ` Florian Weimer
2021-03-26 18:14   ` Andy Lutomirski
2021-03-26 19:34     ` Florian Weimer
2021-03-26 19:47       ` Andy Lutomirski
2021-03-26 20:06         ` Andrew Cooper
2021-03-26 20:35         ` Florian Weimer
2021-03-26 20:43           ` H.J. Lu
2021-03-26 20:48           ` Andy Lutomirski
2021-03-26 21:11             ` Florian Weimer
2021-03-26 21:21               ` Andy Lutomirski [this message]
2021-03-26 13:32 ` David Laight

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=C624A1B5-45EE-491C-B43B-5605D48273E9@amacapital.net \
    --to=luto@amacapital.net \
    --cc=carlos@redhat.com \
    --cc=chang.seok.bae@intel.com \
    --cc=dalias@libc.org \
    --cc=fw@deneb.enyo.de \
    --cc=hjl.tools@gmail.com \
    --cc=libc-alpha@sourceware.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=x86@kernel.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 read-only IMAP folder(s) and NNTP newsgroup(s).