From: Gabriel Krisman Bertazi <krisman@collabora.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: "Peter Zijlstra" <peterz@infradead.org>,
"André Almeida" <andrealmeid@collabora.com>,
"Thomas Gleixner" <tglx@linutronix.de>,
"Ingo Molnar" <mingo@redhat.com>,
"Darren Hart" <dvhart@infradead.org>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
"Steven Rostedt" <rostedt@goodmis.org>,
"Sebastian Andrzej Siewior" <bigeasy@linutronix.de>,
"Collabora kernel ML" <kernel@collabora.com>,
"Linux API" <linux-api@vger.kernel.org>,
"GNU C Library" <libc-alpha@sourceware.org>,
"Michael Kerrisk" <mtk.manpages@gmail.com>,
"Davidlohr Bueso" <dave@stgolabs.net>
Subject: Re: [PATCH v3 2/6] futex2: Implement vectorized wait
Date: Thu, 16 Sep 2021 12:36:21 -0400 [thread overview]
Message-ID: <874kak8ol6.fsf@collabora.com> (raw)
In-Reply-To: <CAK8P3a3Bka5R4dmHE_+xuKTCtMaSZEYvT9jAz7QbgnF_CkeoNQ@mail.gmail.com> (Arnd Bergmann's message of "Thu, 16 Sep 2021 13:50:14 +0200")
Arnd Bergmann <arnd@arndb.de> writes:
> On Thu, Sep 16, 2021 at 1:22 PM Peter Zijlstra <peterz@infradead.org> wrote:
>>
>> On Thu, Sep 16, 2021 at 12:10:25AM -0400, Gabriel Krisman Bertazi wrote:
>>
>> > I find this weird. I'm not even juts talking about compat, but even on
>> > native 32-bit. But also, 32 applications on 64, which is a big use
>> > case for games.
>>
>> Seriously, people still make 32bit applications today? And for legacy
>> games, I would think the speed increase of modern CPUs would far offset
>> this little inefficiency.
>
> There are 32-bit Windows games apparently, because it's easier to build it
> that way than having both 32-bit and 64-bit versions.
Yes, many modern, recently released, tiple-A Windows games running over
Proton/Wine are published only in 32-bit. We also keep a 32-bit Proton
for that reason.
> There may be native 32-bit games built for Linux from the same sources when
> that is not written portably, not sure if that's a thing.
>
> One important reason to use compat mode is for cost savings when you can
> ship an embedded system with slightly less RAM by running 32-bit user space
> on it. We even still see people running 32-bit kernels on Arm boxes that have
> entry-level 64-bit chips, though I hope that those will migrate the
> kernel to arm64
> even when they ship 32-bit user space.
>
> Similar logic applies to cloud instances or containers. Running a 32-bit
> Alpine Linux in a container means you can often go to a lower memory
> instance on the host compared to a full 64-bit distro.
>
> Arnd
--
Gabriel Krisman Bertazi
next prev parent reply other threads:[~2021-09-16 16:39 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-13 17:52 [PATCH v3 0/6] futex2: Add wait on multiple futexes syscall André Almeida
2021-09-13 17:52 ` [PATCH v3 1/6] futex: Prepare for futex_wait_multiple() André Almeida
2021-09-13 17:52 ` [PATCH v3 2/6] futex2: Implement vectorized wait André Almeida
2021-09-14 1:03 ` Gabriel Krisman Bertazi
2021-09-14 17:18 ` André Almeida
2021-09-16 4:10 ` Gabriel Krisman Bertazi
2021-09-16 11:20 ` Peter Zijlstra
2021-09-16 11:50 ` Arnd Bergmann
2021-09-16 13:37 ` Steven Rostedt
2021-09-16 16:36 ` Gabriel Krisman Bertazi [this message]
2021-09-13 17:52 ` [PATCH v3 3/6] futex2: wire up syscall for x86 André Almeida
2021-09-13 17:52 ` [PATCH v3 4/6] futex2: wire up syscall for ARM André Almeida
2021-09-13 17:52 ` [PATCH v3 5/6] selftests: futex2: Add waitv test André Almeida
2021-09-14 1:11 ` Gabriel Krisman Bertazi
2021-09-13 17:52 ` [PATCH v3 6/6] selftests: futex2: Test futex_waitv timeout André Almeida
2021-09-14 1:05 ` [PATCH v3 0/6] futex2: Add wait on multiple futexes syscall Gabriel Krisman Bertazi
2021-09-14 3:07 ` André Almeida
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=874kak8ol6.fsf@collabora.com \
--to=krisman@collabora.com \
--cc=andrealmeid@collabora.com \
--cc=arnd@arndb.de \
--cc=bigeasy@linutronix.de \
--cc=dave@stgolabs.net \
--cc=dvhart@infradead.org \
--cc=kernel@collabora.com \
--cc=libc-alpha@sourceware.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=mtk.manpages@gmail.com \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
/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).