On Mon, Mar 29, 2021 at 10:15:14AM +0800, Zhangfei Gao wrote:
Have found the reason, hpre is connected to another smmu, whose dvm is not enabled by the bios :(.
Oh ok that's good news, explains why I couldn't reproduce it with the zip engine.
sudo busybox devmem 0x2001c0030 32 0x1 // is error 0x9 // is correct With the updated bios, have passed stress test in the weekend: 1000 times async test, 5w times of sync test. Will update the bios of the openlab board as well.
By the way, still one uncertainty. Is is possible thp collapse the memory just using by dma?
I'm not sure I understand the question. You can have DMA cause THP collapse, but it's done by a separate thread, khugepaged, that regularly scans memory, looking to transform contiguous small-pages mappings into huge pages:
1. Create a virtually-contiguous 2MB region of 4k pages:
for (page = 0; page < SZ_2M; page += SZ_4K) { mmap(base + page, SZ_4K, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS | MAP_FIXED, 0, 0); /* Allocate half of the 4k pages now */ if (page % SZ_8K) *(char *)(base + page) = 1; }
2. Issue DMA for the other pages in the range, causing IOPF to allocate the remaining pages. 3. If khugepaged scans that region (reduce scan_sleep_millisecs to increases chances of that), it will collapse it into a huge page. I check /proc/self/smaps before an after to see whether an address ranges has AnonHugePages or not.
You can also cause huge page allocation from IOPF, by allocating a 2MB mapping and initializing it using DMA.
the spin lock has no effect to device.
Which spinlock?
Thanks, Jean