https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212681
--- Comment #59 from rai...@ultra-secure.de ---
BYTE UNIX Benchmarks (Version 4.1.0)
System -- freebsd11
Start Benchmark Run: Mon Feb 13 17:28:56 CET 2017
3 interactive users.
5:28PM up 3:06, 3 users, load averages: 0.62, 0.69, 0
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212681
--- Comment #58 from Roger Pau Monné ---
(In reply to rainer from comment #57)
You can also use plain dd to write to a block device, just like you do with
dc3dd. Can you actually also try if plain dd shows the same slowness with
writing to
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212681
--- Comment #57 from rai...@ultra-secure.de ---
Well, I did do dd test, but they only write on a filesystem.
It was (back then) most likely on ZFS, with compression etc. that changed the
results.
Esp. if I just write zeros from /dev/null.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212681
--- Comment #56 from Roger Pau Monné ---
(In reply to rainer from comment #55)
Yes, you won't see those tunables in sysctl.
Then again I'm quite lost, because you did test a plain dd, and that was
actually working fine (and yielding resul
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212681
--- Comment #55 from rai...@ultra-secure.de ---
I can't see these tunables in sysctl.
But:
hw.xen.disable_pv_disks=1
is responsible for the slight increases in disk-performance.
--
You are receiving this mail because:
You are the assign
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212681
--- Comment #54 from Roger Pau Monné ---
Created attachment 179940
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=179940&action=edit
Selectively disable PV optimizations
--
You are receiving this mail because:
You are the assi
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212681
--- Comment #53 from Roger Pau Monné ---
I'm attaching another patch that will allow to selectively disable some PV
optimizations, you will have to play with the following tunables, and see if
you can find which one(s) causes the VM to go
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212681
--- Comment #52 from rai...@ultra-secure.de ---
Yes.
So, 60%-70% increase.
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-xen@freebsd.org mailing list
https
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212681
--- Comment #51 from Roger Pau Monné ---
(In reply to rainer from comment #49)
So performance is slightly better with this patch? (IIRC you where getting
17M/s and with the patch you get 26M/s)
--
You are receiving this mail because:
You
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212681
--- Comment #50 from rai...@ultra-secure.de ---
Output from the xen-server:
xe vm-list name-label=i-129-1591-VM params=all
uuid ( RO) : 30f354c0-6a14-0dea-2be2-070a38ca2fc0
name-label ( RW): i-1
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212681
--- Comment #49 from rai...@ultra-secure.de ---
I switched back the OS-type to FreeBSD 10 64bit.
I also booted back into a stock kernel and then the XENTIMER-LAPIC change went
through without a freeze.
I recompiled (a clean source-tree) wi
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212681
--- Comment #48 from Roger Pau Monné ---
(In reply to Roger Pau Monné from comment #46)
OK, I've re-done the patch to disable the Xen enlightenments, could you please
try it again? Although the LAPIC timer issue is also concerning.
--
Y
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212681
Roger Pau Monné changed:
What|Removed |Added
Attachment #179844|0 |1
is obsolete|
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212681
--- Comment #46 from Roger Pau Monné ---
(In reply to rainer from comment #44)
This panic trace is very disturbing, I'm a little bit confused. Which kind of
guest are you running?
The trace shows xen_start -> hammer_time_xen and this path
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212681
--- Comment #45 from Roger Pau Monné ---
(In reply to rainer from comment #43)
Hm, that's certainly not good, switching to the LAPIC timer shouldn't cause the
VM to freeze, I've tried it and it works just fine. Do you see anything in the
c
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212681
--- Comment #44 from rai...@ultra-secure.de ---
Created attachment 179858
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=179858&action=edit
Screenshot of panic
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212681
--- Comment #43 from rai...@ultra-secure.de ---
# sysctl -w kern.timecounter.hardware=ACPI-fast
Already had that.
IIRC, it's mentioned in the bug about moving a VM freezing it...
# sysctl -w kern.eventtimer.timer=LAPIC
and that freezes t
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212681
--- Comment #42 from Roger Pau Monné ---
Created attachment 179844
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=179844&action=edit
Disable all the Xen enlightments
--
You are receiving this mail because:
You are the assignee
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212681
--- Comment #41 from Roger Pau Monné ---
Can you try to change the event timer and the time counter to a different one
than the Xen one:
# sysctl -w kern.timecounter.hardware=ACPI-fast
# sysctl -w kern.eventtimer.timer=LAPIC
And finally
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212681
--- Comment #40 from rai...@ultra-secure.de ---
Here:
(freebsd11 ) 1 # sysctl -a |grep xbd
hw.xbd.xbd_enable_indirect: 0
dev.xbd.2.xenstore_peer_path: /local/domain/0/backend/vbd3/13/768
dev.xbd.2.xenbus_peer_domid: 0
dev.xbd.2.xenbus_conne
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212681
--- Comment #39 from Roger Pau Monné ---
(In reply to rainer from comment #36)
There's clearly something wrong there, you are not receiving as many interrupts
as you should be, this is what I usually see when running dc3dd:
irq808: xen_et
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212681
--- Comment #38 from rai...@ultra-secure.de ---
Well, for some it works, for some it doesn't.
The 10% I also see when writing to a RAM-disk.
I'd just like to know how I can determine where all the performance is lost.
--
You are receivin
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212681
--- Comment #37 from Roger Pau Monné ---
(In reply to Roger Pau Monné from comment #33)
So I've run the dc3dd test on a FreeBSD VM, with 4 vCPUs and 4GB of RAM,
against a block device on a spinning disk, nothing fancy, and this is what I
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212681
--- Comment #36 from rai...@ultra-secure.de ---
Hi,
I added the output.
As I said, I could give ssh access to the box, if you want.
I would need your ssh key.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212681
--- Comment #35 from rai...@ultra-secure.de ---
Created attachment 179838
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=179838&action=edit
vmstat -ai while running dc3dd
--
You are receiving this mail because:
You are the assig
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212681
--- Comment #34 from rai...@ultra-secure.de ---
Created attachment 179837
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=179837&action=edit
vmstat -ai before running dc3dd
--
You are receiving this mail because:
You are the assi
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212681
--- Comment #33 from Roger Pau Monné ---
(In reply to rainer from comment #32)
That was a possible outcome. I have a box half-setup for this, I will try to
reproduce it tomorrow (Saturday), and see if I can get any useful data. As a
last t
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212681
--- Comment #32 from rai...@ultra-secure.de ---
No, can't see anything.
I believe I compiled the kernel correctly:
(freebsd11 ) 0 # strings /boot/kernel/kernel|grep Freez
Sequencer On QFreeze and Complete list:
Chan %d Freeze simq (loopdo
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212681
--- Comment #31 from Roger Pau Monné ---
You should see the messages in dmesg (if any), just execute:
# dmesg
As root from the console after having run your workload.
--
You are receiving this mail because:
You are the assignee for the
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212681
--- Comment #30 from rai...@ultra-secure.de ---
Hi,
I compiled a new kernel with this.
Where would the messages show up?
Anything special I need to add to GENERIC?
Or a flag at booting?
Sorry to sound so dumb. I stopped paying attention t
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212681
--- Comment #29 from Roger Pau Monné ---
Created attachment 179717
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=179717&action=edit
Initial debug patch
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212681
--- Comment #28 from Roger Pau Monné ---
(In reply to rainer from comment #26)
Thanks!
This shows that the guest is mostly inactive (low CPU load), is this correct?
I'm attaching a patch to add some debug to blkfront, please be aware tha
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212681
--- Comment #27 from rai...@ultra-secure.de ---
(In reply to Roger Pau Monné from comment #25)
(freebsd11 ) 0 # kldload pmc
kldload: can't load pmc: module already loaded or in kernel
(freebsd11 ) 1 # kldstat
Id Refs AddressSi
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212681
--- Comment #26 from rai...@ultra-secure.de ---
Created attachment 179716
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=179716&action=edit
flamegraph dtrace
This is running the example on Brendan's page with dtrace.
While the V
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212681
--- Comment #24 from rai...@ultra-secure.de ---
ok,
(freebsd11 ) 64 # pmccontrol -L
SOFT
CLOCK.PROF
CLOCK.HARD
CLOCK.STAT
LOCK.FAILED
PAGE_FAULT.ALL
PAGE_FAULT.READ
PAGE_FAULT.WRITE
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212681
--- Comment #25 from Roger Pau Monné ---
IIRC this was working fine last time I've tried. Have you loaded the pmc module
(kldload pmc), and which CPU are you using? Note that you also need to enable
the PMU support in Xen [0] by passing vp
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212681
--- Comment #23 from rai...@ultra-secure.de ---
Which event specifier should I use?
I can't even run the sample:
(freebsd11 ) 0 # pmcstat –S RESOURCE_STALLS.ANY -O out.pmcstat sleep 10
pmcstat: [options] [commandline]
Measure proc
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212681
--- Comment #22 from Roger Pau Monné ---
Hello,
I don't have much time to look into this right now, could you try to create a
flamegraph [0] of this workload, this way we might be able to identify the
bottleneck(s). If possible you should
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212681
--- Comment #21 from rai...@ultra-secure.de ---
Still a problem on FreeBSD 12:
root@f12test:~ # dc3dd wipe=/dev/ada1
dc3dd 7.2.641 started at 2017-02-06 10:12:31 +0100
compiled options:
command line: dc3dd wipe=/dev/ada1
device size: 10485
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212681
--- Comment #20 from rai...@ultra-secure.de ---
Interestingly enough, even when the backend storage is an SSD-backed ScaleIO
volume (PCIe NVMe), it's not faster.
Linux is faster on SSDs.
--
You are receiving this mail because:
You are the
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212681
--- Comment #19 from rai...@ultra-secure.de ---
Updating to ScaleIO 2.0.3 (and all the latest Hotfixes of XenServer 6.5)
doesn't make a difference.
How would one debug this problem?
--
You are receiving this mail because:
You are the assi
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212681
--- Comment #18 from rai...@ultra-secure.de ---
Hi,
thanks - but it does not make a notable difference.
Neither for the dc3dd -wipe test, nor for my real-world testcase.
I can create a tenant on CloudStack, so you can try it yourself - if
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212681
--- Comment #17 from Roger Pau Monné ---
Hello,
Just a wild guess, but could you try to disable indirect descriptors to see if
that makes a difference? AFAIK XenServer block backends don't implement it, but
it doesn't hurt to try. Just ad
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212681
--- Comment #16 from rai...@ultra-secure.de ---
OK, thanks for the clarification.
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-xen@freebsd.org mailing lis
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212681
Roger Pau Monné changed:
What|Removed |Added
CC||roy...@freebsd.org
--- Comment
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212681
--- Comment #14 from rai...@ultra-secure.de ---
Well, I also get the "ada" thing if I use "Other 64 bit" - which is what we use
for Linux installations and is supposed to be the "optimal" setting (HVM).
--
You are receiving this mail becau
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212681
--- Comment #13 from Sydney Meyer ---
I'm no expert in Cloudstack but perhaps something with the vm template might be
off. Did you tried / is there a possibilty to install FreeBSD with some Linux
template?
--
You are receiving this mail b
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212681
--- Comment #12 from Sydney Meyer ---
I have some 10.3 vm's running on Xen 4.4 with a Debian Linux 4.6 Dom0 and they
give me:
dmesg
xenbusb_back0: on xenstore0
xbd0: 5120MB at device/vbd/51712 on xenbusb_front0
xbd0: features: flush, wr
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212681
--- Comment #11 from rai...@ultra-secure.de ---
Well, I chose "FreeBSD 10 64bit" as OS-type.
In dmesg, I see:
xbd0: attaching as ada0
xbd0: features: write_barrier
xbd0: synchronize cache commands enabled.
sysctl -a |grep xen
kern.vm_gues
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212681
Sydney Meyer changed:
What|Removed |Added
CC||meyer.syd...@gmail.com
--- Comment
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212681
--- Comment #9 from rai...@ultra-secure.de ---
I noticed that the local values are very unstable.
Also, I don't really have access to the Xen side (yet).
I will look into how I can debug this further. I'm merely a consumer of it at
this poi
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212681
--- Comment #8 from k...@pielorz.com ---
(In reply to rainer from comment #7)
Our config here is very similar - HP Proliant DL380 Gen -9- though, with local
SAS disks - which we use for 'Local Storage' for XenServer, and then iSCSI off
to a
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212681
--- Comment #7 from rai...@ultra-secure.de ---
The hardware is HP DL380 Gen 8 servers with 600 or 900 GB SAS disks, running
off a HW RAID controller.
On local storage, the realworld-test is even slower.
I can't run the dc3dd test here and
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212681
--- Comment #6 from k...@pielorz.com ---
(In reply to rainer from comment #5)
Ok, so 'like for like' test see's better performance.
I'm not overly familiar with dc3dd - maybe it's using a "really small block
size" - and on your setup, thi
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212681
--- Comment #5 from rai...@ultra-secure.de ---
10.3-RELEASE-p5:
(server ) 0 # time dd if=/dev/zero of=test.dat bs=64k count=20480
20480+0 records in
20480+0 records out
1342177280 bytes transferred in 1.769942 secs (758317078 bytes/sec)
dd
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212681
--- Comment #4 from k...@pielorz.com ---
(In reply to rainer from comment #3)
Please try a 'like for like' comparison - i.e. run:
dd if=/dev/zero of=test.dat bs=64k count=20480
(Will consume ~1.2Gb of disk space) and see what that comes
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212681
--- Comment #3 from rai...@ultra-secure.de ---
Our hardware is local disks (not SSDs) networked via ScaleIO.
I've run a dd from one disk of a VM to another one and it was very, very slow.
OS: "Other (64bit)" (which is actually a little bit
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212681
Daniel Ylitalo changed:
What|Removed |Added
CC||dan...@blodan.se
--- Comment #2 f
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212681
k...@pielorz.com changed:
What|Removed |Added
CC||k...@pielorz.com
--- Comment #1
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212681
Mark Linimon changed:
What|Removed |Added
Assignee|freebsd-b...@freebsd.org|freebsd-xen@FreeBSD.org
60 matches
Mail list logo
