tg%gmplib.org@localhost (Torbjörn Granlund) writes: > I have Samsung 843T "enterprise" SSD disks on all these systems. I use > "log" as a mount option (via fstab). > > My guest images are plain files created with dd. They contain no > "holes". > > For me, the guests are not just a little slow during a Dom0 compile, > they are useless. It would be nice to find a solution to this problem. > > I have been using many combinations of NetBSD releases (6.1 and 7.0 > primarily) and Xen (4.2 and 4.5 primarily). > > To me, it makes little sense why operations in Dom0 can have such > adverse effects on all guests, while operations in one DomU does not > noticably hurt another DomU. xen provides fair sharing of cpu among dom0 and domU because it controls CPU. For disk, it's more complicated, because operations are forwarded to the dom0 to be actually done. It seems that the fair-sharing of disk among domUs is working. So I wonder how the domU ops that arrive in dom0 share with the native dom0, and I think that's entirely a netbsd issue, not a xen issue. What is your kern.bufq.strategies? Do you perceive reasonable fair-sharing in the dom0 across processes?
Attachment:
signature.asc
Description: PGP signature