Daniel P. Berrangé <berra...@redhat.com> wrote: > On Wed, Feb 06, 2019 at 02:23:28PM +0100, Juan Quintela wrote: >> I haven't seend any problem about using 64 or 128. And it make much >> less contention on the locks. Just change it. > > Isn't there a issue with having a fixed page count given the > very different default page sizes across architectures ? > > x86 is 4kb pages, while ppc64 uses 64kb pages IIUC. > > This would mean current value of 64 pages, would correspond > to 1/4 MB on x86, and 4 MB on ppc64. The new value would > be 1/2 MB on x86 and 8 MB on ppc64.
I saw no difference (on x86 between 64 and 128 pages). Bigger pages means half the contention on the locks and better for compression (see next series). > Should we instead be measuring this tunable in units that > are independant of page size ? eg meansure in KB, with a > requirement that the value is a multiple of the page size. > Then set the default to 512 KB ? See next patch, I just dropped the tunable altogether. Libvirt don't want to support it (difficult to explain), and in the past you asked me to choose a sane value and live with it O:-) It was good for testing, though. Once there, is there a good value for a network packet? I put it in pages because it facilitates the coding, but doing a: CONSTANT/qemu_target_page_size() is not going to complicate anything either. Later, Juan.
