> From: "Theo de Raadt" <dera...@openbsd.org> > Date: Mon, 11 Jul 2016 09:29:16 -0600 > > > > And bufs don't need it either. Have you actually cranked your buffer > > > cache that high? I have test this, on sparc64 which has unlimited DMA > > > reach due to the iommu. The system comes to a crawl when there are > > > too many mbufs or bufs, probably due to management structures unable > > > to handle the pressure. > > > > No, I didn't know that. I assumed that having a few more GBs of bufcache > > would help the performance. Until that is the case, 64bit dma does not > > make much sense. > > BTW, my tests were on a 128GB sun4v machine. Sun T5140. They are > actually fairly cheap used these days. > > A maximum sized buffer cache should be fast. However there is no need > for it to be dma-reachable. Bob's buffer cache flipper can bounce it > to high memory easily after it is read the first time, and preserve it > in otherwise unused memory. A buffer cache object of that sort is > never written back to the io path. Also, it can be discarded in any > memory shortage condition without cost.
Except that the flipper isn't enabled yet and that the backpressure mechanism is busted somewhow. At least that is what the recent experiment with cranking up the buffer cache limit showed us. People screamed and we backed the change out again. And there were problems on amd64 and sparc64 alike. What we probably need is help fixing the buffer cache. Then we can enable the flipper. And then we see if 64-bit DMA is still a requirement.
