On Thu, Sep 19, 2019 at 8:47 AM Adam Borowski <[email protected]> wrote: > > On Thu, Sep 19, 2019 at 08:10:47AM -0700, Dan Williams wrote: > > On Thu, Sep 19, 2019 at 4:56 AM Adam Borowski <[email protected]> wrote: > > > Hi! > > > If I try to change the mode of a devdax namespace that's in use (mapped by > > > some process), ndctl hangs: > > > > Is it merely mapped, or might the pages be actively pinned / in use by > > another part of the kernel? The kernel has no choice but to wait for > > active page pins to drain. Can you get a stack trace of the process > > with the dev-dax instance mapped? > > Looks like the behaviour is different depending on what the other process > is: > * with qemu, the hang is 100% reproducible, the guest continues to work and > cleanly exits -- qemu does not exit on its own (unlike normal case) but > SIGTERM terminates it correctly. Thus, qemu is not stuck, only ndctl is. > * with mere mmap() (I've used vmemcache) ndctl allows > reconfiguring the namespace. No hang. > > My way to start qemu is: > .---- > #!/bin/sh > NET="-net bridge -net nic" > DISK=eoan-devdax.disk > > exec qemu-system-x86_64 -enable-kvm -m 4096,slots=2,maxmem=16G -smp 8 $NET \ > -drive if=none,id=hd,file="$DISK",format=raw,cache=unsafe,discard=on \ > -device virtio-scsi-pci,id=scsi -device scsi-hd,drive=hd \ > -M pc,nvdimm,nvdimm-persistence=mem-ctrl \ > -object > memory-backend-file,id=mem1,share=on,mem-path=/dev/dax0.0,size=4225761280,align=2M,pmem=on > \ > -device nvdimm,id=nvdimm1,memdev=mem1,label-size=256K \ > -vnc :5
Ok, I'll take a look. At first glance nothing in that config should be holding an indefinite page pin, so it does smell like a kernel bug. _______________________________________________ Linux-nvdimm mailing list [email protected] https://lists.01.org/mailman/listinfo/linux-nvdimm
