Re: Sun hardware in need of a good home

[Mark Morgan Lloyd]

On 24/10/16 14:30, Bob Ham wrote:

Hi all,

Let me tell you a little story.  Many moons ago, while I was living away
from Bristol, a man appeared at a meeting of the Bristol and Bath Linux
User Group offering abundant gifts to all and sundry.  Inside the boot
of his car lay a treasure trove of Sun computers, as I understand,
originating from the University of Bath.  A number of these were taken
by a LUG regular, a hacker of great skill named John Honniball, who took


Jon Honeyball was pleasantly notorious for writing magazine columns from 
the POV of somebody who owned the sort of equipment with a spec that 
mere mortals wouldn't dream of for 18 months or so. The result of this 
was that the "British Standard Honeyball" unit was a bit of a movable 
feast when it came to equating it to actual amounts of RAM, clock speed 
and so on :-)



them in order to offer the gems to any who sought to learn the ways of
the SPARC and the arcane magic of Engineering Workstations The Right
Way.  When I returned to Bristol I was honoured to be offered, and
accept, a SPARCclassic from John.

Some years later, after I had left Bristol and returned again, another
LUG regular, a Unix wizard from the University of Bristol's department
of physics named Winnie Lacesso, notified us that there were a number of
Sun workstations being disposed of by her department.  (The same
department providing part of the computing grid for the LHC no less.)  I
took the opportunity to visit the department and acquire a SPARCstation
4, along with two Sun monitors, from the learned folks.

Now, I live in Liverpool.  I have tinkered and explored and learned.  I
have gained a great deal from these gifts.  However, I have moved on and
I feel it is right that instead of gathering dust, these gems should
again be offered to any who seek.  So, in need of a good home are:


[Etc.] I sympathise, but unfortunately some of the things that I'll have 
to get rid of at some point are orders of magnitude bigger and heavier 
than what you've got.


--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]

Re: [PATCH] sparc64: Handle extremely large kernel TSB range flushes sanely.

[David Miller]

From: James Clarke 
Date: Thu, 27 Oct 2016 17:02:32 +0100

> I was just testing it on the IIIi when I got this. Anyway, it seems to work 
> fine.
> It hasn’t (yet) had one of the stupidly high allocations, but it did flush a 
> block
> of 3658 pages just fine (assuming the flush actually worked). Similarly for 
> the T1.

Thanks for testing.  I'll post the final patch I committed.

> The cut-off seems pretty arbitrary, and the only way to determine it properly 
> would
> be benchmarking (or finding out what the relevant delays are). Given x86 uses 
> 33,
> 32 or 64 seem perfectly fine, but going into the hundreds doesn’t sound stupid
> either... For such small numbers it’s probably hardly going to matter.

It's not too hard to write a kernel module which just does dummy TLB flushes in
the loop and count the cycles using the %tick register.  And I plan to hack on
something like that soon'ish.

Another part of the equation is that it blows away, at a minimum, all kernel
TLB entries.  And that has a certain cost too.

Re: [PATCH] sparc64: Handle extremely large kernel TSB range flushes sanely.

[David Miller]

From: James Clarke 
Date: Thu, 27 Oct 2016 09:25:36 +0100

> I’ve run it on the T5 and it seems to work without lockups:
> 
> [5948090.988821] vln_init: *vmap_lazy_nr is 32754
> [5948090.989943] vln_init: lazy_max_pages() is 32768
> [5948091.157381] TSB[insmod:261876]: DEBUG flush_tsb_kernel_range 
> start=10006000 end=f000 PAGE_SIZE=2000
> [5948091.157530] TSB[insmod:261876]: DEBUG flush_tsb_kernel_range 
> start=0001 end=00058c00 PAGE_SIZE=2000
> [5948091.158240] vln_init: vmap_lazy_nr is caeb1c
> [5948091.158252] vln_init: *vmap_lazy_nr is 0
> [5948091.159311] vln_init: lazy_max_pages() is 32768
> ... continues on as normal ...
> 
> (again, that’s my debugging module to see how close the system is to a flush)
> 
> I can't (yet) vouch for the IIIi, but when it comes back up I’ll give it a 
> go[1].
> I'll also put it on the T1 at some point today, but it *should* also work 
> since
> it's using the same sun4v/hypervisor implementation as the T5.

I'm about to test it on my IIIi and will commit this if it seems to work 
properly.

I guess you have no opinion about the cut-off choosen? :-)

Anyways, we can fine tune it later.

Re: [PATCH] sparc64: Handle extremely large kernel TSB range flushes sanely.

[James Clarke]

> On 27 Oct 2016, at 16:51, David Miller  wrote:
> 
> From: James Clarke 
> Date: Thu, 27 Oct 2016 09:25:36 +0100
> 
>> I’ve run it on the T5 and it seems to work without lockups:
>> 
>> [5948090.988821] vln_init: *vmap_lazy_nr is 32754
>> [5948090.989943] vln_init: lazy_max_pages() is 32768
>> [5948091.157381] TSB[insmod:261876]: DEBUG flush_tsb_kernel_range 
>> start=10006000 end=f000 PAGE_SIZE=2000
>> [5948091.157530] TSB[insmod:261876]: DEBUG flush_tsb_kernel_range 
>> start=0001 end=00058c00 PAGE_SIZE=2000
>> [5948091.158240] vln_init: vmap_lazy_nr is caeb1c
>> [5948091.158252] vln_init: *vmap_lazy_nr is 0
>> [5948091.159311] vln_init: lazy_max_pages() is 32768
>> ... continues on as normal ...
>> 
>> (again, that’s my debugging module to see how close the system is to a flush)
>> 
>> I can't (yet) vouch for the IIIi, but when it comes back up I’ll give it a 
>> go[1].
>> I'll also put it on the T1 at some point today, but it *should* also work 
>> since
>> it's using the same sun4v/hypervisor implementation as the T5.
> 
> I'm about to test it on my IIIi and will commit this if it seems to work 
> properly.
> 
> I guess you have no opinion about the cut-off choosen? :-)
> 
> Anyways, we can fine tune it later.

I was just testing it on the IIIi when I got this. Anyway, it seems to work 
fine.
It hasn’t (yet) had one of the stupidly high allocations, but it did flush a 
block
of 3658 pages just fine (assuming the flush actually worked). Similarly for the 
T1.

The cut-off seems pretty arbitrary, and the only way to determine it properly 
would
be benchmarking (or finding out what the relevant delays are). Given x86 uses 
33,
32 or 64 seem perfectly fine, but going into the hundreds doesn’t sound stupid
either... For such small numbers it’s probably hardly going to matter.

Tested-by: James Clarke 

James

Re: ravirin down

[James Clarke]

Thanks! I'll put the new kernel on there.

James

> On 27 Oct 2016, at 15:11, rod  wrote:
> 
> James,
> 
> He's back up.  Let me know if you need anything else.
> 
> Rod
> 
>> On 10/27/2016 7:07 AM, James Clarke wrote:
>> Hi Rod,
>> It seems ravirin has been down for at least the past few days. Could you 
>> please
>> give it some love? If it’s crashed/hung with CPU lockups, I’ve built a 4.9
>> kernel with a patch to fix this which I’d like to test.
>> 
>> Thanks,
>> James
>> 

ravirin down

[James Clarke]

Hi Rod,
It seems ravirin has been down for at least the past few days. Could you please
give it some love? If it’s crashed/hung with CPU lockups, I’ve built a 4.9
kernel with a patch to fix this which I’d like to test.

Thanks,
James

Re: [PATCH] sparc64: Handle extremely large kernel TSB range flushes sanely.

[James Clarke]

> On 27 Oct 2016, at 02:27, James Clarke  wrote:
> 
>> On 26 Oct 2016, at 22:02, David Miller  wrote:
>> 
>> From: James Clarke 
>> Date: Wed, 26 Oct 2016 21:05:36 +0100
>> 
>>> Thanks for this, it's now compiling. I'll let you know if it works
>>> within the next 24 hours.
>> 
>> Thanks.
>> 
>>> Before I forget, what do you think about the following patch? I know
>>> Debian used to use the 64-bit kernel for a 32-bit sparc userland, and so
>>> "Architecture: sparc" was correct, but obviously sparc64 also exists. It
>>> seems more sane to make sparc64 default to "Architecture: sparc64", with
>>> sparc users needing to override this with KBUILD_DEBARCH if they want
>>> to, rather than providing a setup that's broken out of the box for
>>> sparc64 users.
>>> 
>>> From: James Clarke 
>>> Date: Wed, 26 Oct 2016 20:17:10 +0100
>>> Subject: [PATCH] builddeb: Add support for sparc64
>>> 
>>> Signed-off-by: James Clarke 
>> 
>> I don't know.
>> 
>> I still personally use a 32-bit userland on my sparc64 systems because
>> that is what performs the best and is what I will be using for as long
>> as I possibly can.
>> 
>> I've actually never used this target, is this for build the kernel or
>> userland components?
> 
> Yes, make pkg-deb builds kernel, firmware, headers and linux-libc packages.
> By the way, the first build I made of 4.9 (using Debian’s 4.8 config as old
> config) wouldn’t boot, since:
> 
> * sunvdc module needs _mcount
> * sunvnet module needs _mcount and count_bits
> * crc32c_sparc64 module needs _mcount and VISenter
> [* raid6_pq module needs memcpy, though that’s just for a data partition]
> 
> The workaround is not to use CONFIG_MODVERSIONS, but this wasn’t at all clear
> at first. This is because of d3867f0483, which moved these to being exported 
> in
> their .S.
> 
> Anyway, the new kernel is running now and being stress-tested.

Hi David,
I’ve run it on the T5 and it seems to work without lockups:

[5948090.988821] vln_init: *vmap_lazy_nr is 32754
[5948090.989943] vln_init: lazy_max_pages() is 32768
[5948091.157381] TSB[insmod:261876]: DEBUG flush_tsb_kernel_range 
start=10006000 end=f000 PAGE_SIZE=2000
[5948091.157530] TSB[insmod:261876]: DEBUG flush_tsb_kernel_range 
start=0001 end=00058c00 PAGE_SIZE=2000
[5948091.158240] vln_init: vmap_lazy_nr is caeb1c
[5948091.158252] vln_init: *vmap_lazy_nr is 0
[5948091.159311] vln_init: lazy_max_pages() is 32768
... continues on as normal ...

(again, that’s my debugging module to see how close the system is to a flush)

I can't (yet) vouch for the IIIi, but when it comes back up I’ll give it a 
go[1].
I'll also put it on the T1 at some point today, but it *should* also work since
it's using the same sun4v/hypervisor implementation as the T5.

Thanks,
James

[1] Not sure how long that will take...