Re: amd64: svs

[Jaromír Doleček]

2018-01-08 10:24 GMT+01:00 Maxime Villard :
>
> As far as SVS is concerned, it is not needed: each time an L4 slot is
added
> (pmap_get_ptp) or removed (pmap_free_ptp), SVS only applies the change in
the
> user page tables.
>
> The TLB is then flushed as usual: the slots that are stale in the pmap
page
> tables are also stale in the user page tables, so the flush has the same
effect
> regardless of whether the CPU is executing in userland or in the kernel.
>
> There are possible optimizations, like not sending TLB-flush IPIs to CPUs
that
> are known to have performed a kernel<->user transition between the time
when a
> page got removed from the page tables and the time we decided to flush
the TLB
> as a result.


If I understand correctly, basically main idea is that we keep the same
address space, but simply unmap kernel pages on return to user space.

Linux went with just completely separate address spaces for kernel and user
space on the affected Intel cpus. The address space switch could be made
cheaper when cpu has PCID, which Linux already supports.

Do you reckon SVS has potential of having lower overall overhead than
separate address spaces + PCID? Alternatively, do you think SVS would
benefit if we added PCID support to x86 pmap?

Since we already have support for Alpha ASN which is similar concept as the
x86 PCID, perhaps it would not be overly complex to implement the PCID
support.

Jaromir

Re: Reading a DDS tape with 2M blocks

[Warner Losh]

On Jan 9, 2018 3:59 PM, "Greg Troxel"  wrote:


Edgar Fuß  writes:

> I have a DDS tape (written on an IRIX machine) with 2M blocks.
> Any way to read this on a NetBSD machine?
> My memories of SCSI ILI handling on DDS are fuzzy. I remember you can
operate
> these tapes in fixed or variable block size mode, where some values in
the CDB
> either mean blocks or bytes. I thought in variable mode, you could read
block
> sizes other than the (virtual) physical block size of the tape.

Did you try

dd if=/dev/rsd0d of=FILE bs=2m

or similar?  I believe that dd does reads of the given bs and these
reads are passed to the tape device driver which then does reads of that
size from the hardware, and that this then works fine.


Might need MAXPHYS of 2m too...

Warner

Re: Reading a DDS tape with 2M blocks

[Greg Troxel]

Edgar Fuß  writes:

> I have a DDS tape (written on an IRIX machine) with 2M blocks.
> Any way to read this on a NetBSD machine?
> My memories of SCSI ILI handling on DDS are fuzzy. I remember you can operate 
> these tapes in fixed or variable block size mode, where some values in the 
> CDB 
> either mean blocks or bytes. I thought in variable mode, you could read block 
> sizes other than the (virtual) physical block size of the tape.

Did you try

dd if=/dev/rsd0d of=FILE bs=2m

or similar?  I believe that dd does reads of the given bs and these
reads are passed to the tape device driver which then does reads of that
size from the hardware, and that this then works fine.


signature.asc
Description: PGP signature

Re: amd64: svs

[maya]

common pmap uses ASIDs too, I was curious about it before hearing about
the vulnerability because I thought it might have performance benefits.

Reading a DDS tape with 2M blocks

[Edgar Fuß]

I have a DDS tape (written on an IRIX machine) with 2M blocks.
Any way to read this on a NetBSD machine?
My memories of SCSI ILI handling on DDS are fuzzy. I remember you can operate 
these tapes in fixed or variable block size mode, where some values in the CDB 
either mean blocks or bytes. I thought in variable mode, you could read block 
sizes other than the (virtual) physical block size of the tape.

mutex vs turnstile

[Mateusz Guzik]

Some time ago I wrote about performance problems when doing high -j
build.sh and made few remarks about mutex implementation.

TL;DR for that one was mostly that cas returns the found value, so
explicit re-reads can be avoided. There are also avoidable explicit
barriers (yes, I know about the old Opteron errata).

I had another look and have a remark definitely worth looking at (and
easy to fix). Unfortunately I lost my test jig so can't benchmark.

That said, here it is:

After it is is concluded that lock owner sleeps:

ts = turnstile_lookup(mtx);
/*
 * Once we have the turnstile chain interlock, mark the
 * mutex has having waiters.  If that fails, spin again:
 * chances are that the mutex has been released.
 */
if (!MUTEX_SET_WAITERS(mtx, owner)) {
turnstile_exit(mtx);
owner = mtx->mtx_owner;
continue;
}

Note that the lock apart from being free, can be:
1. owned by the same owner, which is now running

In this case the bit is set spuriously and triggers slow path
unlock.

2. owned by a different owner, which is NOT running

Assuming the owner still has the lock and is not running after
turnstile_exit, this causes extra trip.

That said, proposed change is trivial and follows what FreeBSD is doing:
re-read and abort sleep unless the lock is owned by an off-cpu thread.

Note there is a minor optimisation of not setting the bit if already
seen.

That said, the minimal fix would look like this (untested):
ts = turnstile_lookup(mtx);
owner = mtx->mtx_owner;
if (mutex_oncpu(owner) || !MUTEX_SET_WAITERS(mtx, owner))
turnstile_exit(mtx);
owner = mtx->mtx_owner;
continue;
}

If value from cas was to be preserved it would definitely make sense
to re-test failed MUTEX_SET_WAITERS while still holding the turnstile lock.

It looks like rw locks can use a similar treatment.

Fun fact is that implementation on Illumos behaves worse in this regard:
it sets the waiters bit regardless *who* owns the lock (or whether they
are running), but then only goes to sleep if the *original* owner has
the lock.

-- 
Mateusz Guzik