The allocation size is function of MAXPHYS / PAGE_SIZE * (queue size), which is e.g. for i386 and 128 queue size: 64k / 4k / 128 = 16*128 = 2048. It's MAXPHYS _divided_ by PAGE_SIZE.
I've looked at virtio_alloc_vq() in little bit of detail. The way I count how allocsize is computed, I arrive to something like 36104 bytes plus twice alignment to 4096 boundary.
When I boot kernel printing the allocsize, it prints 45056 allocsize for the vioscsi queue of size 128, and some 81920 bytes for vioif for queue of 256. So in line with expectation.
So is it really that the physical memory would be so fragmented after boot to multiuser, that you cannot get even 11 continual memory pages?
It confuses me that this behaviour doesn't change when I increase the available physical memory, but I used relatively small increase (128MB/256MB/512MB IIRC). Maybe reducing page cache size would help?
Jaromir
2017-05-28 13:48 GMT+02:00 Jonathan A. Kollasch <
jakllsch%kollasch.net@localhost>:
>
> On Sat, May 27, 2017 at 11:21:14AM +0200, Jaromír Doleček wrote:
> > The driver allocates sizeable, but not excessive amounts of memory - mostly
> > working with values like MAXPHYS / PAGE_SIZE * (queue size) for dmamaps/dma
> > memory, where queue size is 128 or so.
>
> No, that's excessive for a contiguous chunk. You can only expect such
> large contiguous allocations to work at boot. Physical memory becomes
> too fragmented after the machine has been up and doing things. We
> could really use a way to defrag physical memory, but doing that is not
> easy.
>
> Jonathan Kollasch