On Mon, Jan 16, 2023 at 10:41:14AM +0100, John Paul Adrian Glaubitz wrote:
> On 1/15/23 01:27, Matthew Wilcox wrote:
> > More useful perhaps is to look at https://popcon.debian.org/
> >
> > There are three machines reporting popcon results. It's dead.
>
> It's an opt-in mechanism that reports
On Mon, 16 Jan 2023 at 10:33, John Paul Adrian Glaubitz
wrote:
>
> Hi Ard!
>
> On 1/14/23 00:25, Ard Biesheuvel wrote:
> > Thanks for reporting back. I (mis)read the debian ports page [3],
> > which mentions Debian 7 as the highest Debian version that supports
> > IA64, and so I assumed that
On 1/15/23 13:04, Sedat Dilek wrote:
Exactly, Debian Popularity Contest was what I was looking for yesterday.
Thanks Matthew.
[1] says in Inst (204701):
Name || Number || %
==
binutils-x86-64-linux-gnu || 101548 || 49.61%
On 1/15/23 01:27, Matthew Wilcox wrote:
More useful perhaps is to look at https://popcon.debian.org/
There are three machines reporting popcon results. It's dead.
It's an opt-in mechanism that reports 190,000 machines running Debian
on x86_64. Do you think that there are only 190,000 servers
On 1/14/23 12:28, Sedat Dilek wrote:
[ ... ]
Best is to ask the Debian release-team or (if there exist) maintainers
or responsibles for the IA64 port - which is an ***unofficial*** port.
Here we go:
https://lists.debian.org/debian-ia64/
Posting address: debian-i...@lists.debian.org
Found
On 1/14/23 12:24, Sedat Dilek wrote:
Example #1: binutils packages
Checking available binutils package for Debian/unstable IA64 (version:
2.39.90.20230110-1):
https://packages.debian.org/sid/binutils <--- Clearly states IA64 as
"unofficial port"
And?
Hi Ard!
On 1/14/23 00:25, Ard Biesheuvel wrote:
Thanks for reporting back. I (mis)read the debian ports page [3],
which mentions Debian 7 as the highest Debian version that supports
IA64, and so I assumed that support had been dropped from Debian.
This page talks about officially supported
On Sun, Jan 15, 2023 at 1:27 AM Matthew Wilcox wrote:
>
> On Sat, Jan 14, 2023 at 12:28:30PM +0100, Sedat Dilek wrote:
> > [ ... ]
> >
> > > Best is to ask the Debian release-team or (if there exist) maintainers
> > > or responsibles for the IA64 port - which is an ***unofficial*** port.
> > >
>
On Sat, Jan 14, 2023 at 12:28:30PM +0100, Sedat Dilek wrote:
> [ ... ]
>
> > Best is to ask the Debian release-team or (if there exist) maintainers
> > or responsibles for the IA64 port - which is an ***unofficial*** port.
> >
>
> Here we go:
>
> https://lists.debian.org/debian-ia64/
>
>
[ ... ]
> Best is to ask the Debian release-team or (if there exist) maintainers
> or responsibles for the IA64 port - which is an ***unofficial*** port.
>
Here we go:
https://lists.debian.org/debian-ia64/
Posting address: debian-i...@lists.debian.org
Found via
On Sat, Jan 14, 2023 at 12:43 AM Ard Biesheuvel wrote:
>
> On Fri, 13 Jan 2023 at 22:06, John Paul Adrian Glaubitz
> wrote:
> >
> > Hello Ard!
> >
> > > Can I take that as an ack on [0]? The EFI subsystem has evolved
> > > substantially over the years, and there is really no way to do any
> > >
On Fri, 13 Jan 2023 at 22:06, John Paul Adrian Glaubitz
wrote:
>
> Hello Ard!
>
> > Can I take that as an ack on [0]? The EFI subsystem has evolved
> > substantially over the years, and there is really no way to do any
> > IA64 testing beyond build testing, so from that perspective, dropping
> >
On 1/13/23, Linus Torvalds wrote:
> Side note on your access() changes - if it turns out that you can
> remove all the cred games, we should possibly then revert my old
> commit d7852fbd0f04 ("access: avoid the RCU grace period for the
> temporary subjective credentials") which avoided the
Hello Ard!
Can I take that as an ack on [0]? The EFI subsystem has evolved
substantially over the years, and there is really no way to do any
IA64 testing beyond build testing, so from that perspective, dropping
it entirely would be welcomed.
ia64 is regularly tested in Debian and Gentoo
On 13 Jan 2023, at 21:03, Luck, Tony wrote:
>
>> For what it's worth, Debian and Gentoo both have ia64 ports with active
>> users (6.1 looks like it currently fails to build in Debian due to a
>> minor packaging issue, but various versions of 6.0 were built and
>> published, and one of those is
> For what it's worth, Debian and Gentoo both have ia64 ports with active
> users (6.1 looks like it currently fails to build in Debian due to a
> minor packaging issue, but various versions of 6.0 were built and
> published, and one of those is running on the one ia64 Debian builder I
>
On Fri, Jan 13, 2023 at 08:55:41AM +0100, Ard Biesheuvel wrote:
> On Fri, 13 Jan 2023 at 01:31, Luck, Tony wrote:
> >
> > > Yeah, if it was ia64-only, it's a non-issue these days. It's dead and
> > > in pure maintenance mode from a kernel perspective (if even that).
> >
> > There's not much
>> Is it time yet for:
>>
>> $ git rm -r arch/ia64
>>
> Can I take that as an ack on [0]? The EFI subsystem has evolved
> substantially over the years, and there is really no way to do any
> IA64 testing beyond build testing, so from that perspective, dropping
> it entirely would be welcomed.
>
>
On Thu, Jan 12, 2023 at 06:13:16PM -0600, Linus Torvalds wrote:
> On Thu, Jan 12, 2023 at 5:36 PM Mateusz Guzik wrote:
> >
> > To my understanding on said architecture failed cmpxchg still grants you
> > exclusive access to the cacheline, making immediate retry preferable
> > when trying to
On Fri, Jan 13, 2023 at 02:12:50AM +0100, Mateusz Guzik wrote:
> On 1/13/23, Linus Torvalds wrote:
> > Side note on your access() changes - if it turns out that you can
> > remove all the cred games, we should possibly then revert my old
> > commit d7852fbd0f04 ("access: avoid the RCU grace
On Fri, 13 Jan 2023 at 01:31, Luck, Tony wrote:
>
> > Yeah, if it was ia64-only, it's a non-issue these days. It's dead and
> > in pure maintenance mode from a kernel perspective (if even that).
>
> There's not much "simultaneous" in the SMT on ia64. One thread in a
> spin loop will hog the core
On Fri Jan 13, 2023 at 2:15 PM AEST, Linus Torvalds wrote:
> On Thu, Jan 12, 2023 at 9:20 PM Nicholas Piggin wrote:
> >
> > Actually what we'd really want is an arch specific implementation of
> > lockref.
>
> The problem is mainly that then you need to generate the asm versions
> of all those
On Thu, Jan 12, 2023 at 9:20 PM Nicholas Piggin wrote:
>
> Actually what we'd really want is an arch specific implementation of
> lockref.
The problem is mainly that then you need to generate the asm versions
of all those different CMPXCHG_LOOP() variants.
They are all fairly simple, though,
On Thu, Jan 12, 2023 at 7:12 PM Mateusz Guzik wrote:
>
> I did not want to make such a change without redoing the ThunderX2
> benchmark, or at least something else arm64-y. I may be able to bench it
> tomorrow on whatever arm-y stuff can be found on Amazon's EC2, assuming
> no arm64 people show
On Fri Jan 13, 2023 at 10:13 AM AEST, Linus Torvalds wrote:
> [ Adding linux-arch, which is relevant but not very specific, and the
> arm64 and powerpc maintainers that are the more specific cases for an
> architecture where this might actually matter.
>
> See
>
>
>
On Thu, Jan 12, 2023 at 6:31 PM Luck, Tony wrote:
>
> There's not much "simultaneous" in the SMT on ia64.
Oh, I forgot about the whole SoEMT fiasco.
Yeah, that might make ia64 act a bit differently here.
But I don't think anybody cares any more, so I don't think that merits
making this a
> Yeah, if it was ia64-only, it's a non-issue these days. It's dead and
> in pure maintenance mode from a kernel perspective (if even that).
There's not much "simultaneous" in the SMT on ia64. One thread in a
spin loop will hog the core until the h/w switches to the other thread some
number of
[ Adding linux-arch, which is relevant but not very specific, and the
arm64 and powerpc maintainers that are the more specific cases for an
architecture where this might actually matter.
See
28 matches
Mail list logo
