On Saturday 16 August 2014 23:51:46, Philip Guenther wrote:
> > Yes, code patching may be useful. I haven't noticed it used in
> > openbsd before, but I will take a look at sparc64.
>
> Code patching is used currently on i386 and amd64 for the SMAP
> support. Grep for _copyin_stac, for example.
T
On Sat, Aug 16, 2014 at 11:51:46PM -0700, Philip Guenther wrote:
> On Wed, Jul 9, 2014 at 12:26 PM, Stefan Fritsch wrote:
>
> > On Tuesday 08 July 2014 23:53:21, Mark Kettenis wrote:
> >
> ...
>
> > > If we're serious about supporting OpenBSD on (KVM) hypervisors,
> > > something like this makes
On Wed, Jul 9, 2014 at 12:26 PM, Stefan Fritsch wrote:
> On Tuesday 08 July 2014 23:53:21, Mark Kettenis wrote:
>
...
> > If we're serious about supporting OpenBSD on (KVM) hypervisors,
> > something like this makes sense. We tend to try and have a single
> > kernel that runs on the widest rang
On Tuesday 08 July 2014 23:53:21, Mark Kettenis wrote:
> Are these paravirtualization APIs stable? Are they (properly)
> documented somewhere?
Mostly. So far, I am using three things:
1) the paravirtualized EOI. Documented in
Documentation/virtual/kvm/msr.txt in linux source.
2) the MSR to writ
> Date: Tue, 8 Jul 2014 09:22:41 +0200 (CEST)
> From: Stefan Fritsch
>
> Hi,
>
> I have been trying to increase fork performance of openbsd/amd64 on KVM.
> It turns out that when I increase the number of CPUs of a VM from 1 to 3,
> a fork+exit micro benchmark is slowed down by a factor of 7.
>
Hi,
I have been trying to increase fork performance of openbsd/amd64 on KVM.
It turns out that when I increase the number of CPUs of a VM from 1 to 3,
a fork+exit micro benchmark is slowed down by a factor of 7.
The main reason for this seems to be a very large number of cross-CPU TLB
flushes
