search for: thunderx2

Hi all, I am looking at the scheduling model of the ThunderX2. I am trying to figure out the cost of the LDADDALX instruction. The following program’s output is: name LDADDALX; class 872 microops 65535 I would have assumed that the microops are less than 20. The ThunderX2 has a detailed cost model for LSE. Could somebody tell me what I am doing wrong? Cheers...

Without seeing more details it's impossible to tell, but it might have been me. https://github.com/llvm/llvm-project/commit/6102310d814ad73eab60a88b21dd70874f7a056f#diff-0f9a49c4e31c311a0010e126cd785f08 changed PHI node equality check, but there were some users that implicitly depended on the old definition of the PHI equality, and didn't verify their implicit assumptions with reality,

> On Sep 22, 2017, at 10:34 AM, Thorsten Schütt via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi all, > > I am looking at the scheduling model of the ThunderX2. I am trying to figure out the cost of the LDADDALX instruction. The following program’s output is: > name LDADDALX; class 872 > microops 65535 > I would have assumed that the microops are less than 20. The ThunderX2 has a detailed cost model for LSE. Could somebody tell me what I am doing...

...t; > > > llvm::StringRef ref = II.getName(llvm::AArch64::LDADDALX); > > llvm::MCInstrDesc d = II.get(llvm::AArch64::LDADDALX); > > > > printf("name %s; class %d\n", ref.str().c_str(), d.SchedClass); > > > > printf("microops %d\n", llvm::ThunderX2T99Model.getSchedClassDesc(d. > SchedClass)->NumMicroOps); > > > > return 0; > > } > > > > /* > > LDADDALB_LDADDALH_LDADDALW_LDADDALX = 872, in Sched enum > > */ > > I bet the problem is that “WriteAtomic” is marked unsupported, so it gets &gt...

...ate_data in vhost_transport_send_pkt, > > > and return at once if !vq->private_data. This makes user connect() > > > be returned with ECONNREFUSED. > > > > > > After this patch, kata-runtime (with vsock enabled) boottime reduces from > > > 3s to 1s on ThunderX2 arm64 server. > > > > > > [1] https://github.com/kata-containers/runtime/issues/1917 > > > > > > Reported-by: Ning Bo <n.b at live.com> > > > Signed-off-by: Jia He <justin.he at arm.com> > > > --- > > > drivers/vhost/vsock....

...ate_data in vhost_transport_send_pkt, > > > and return at once if !vq->private_data. This makes user connect() > > > be returned with ECONNREFUSED. > > > > > > After this patch, kata-runtime (with vsock enabled) boottime reduces from > > > 3s to 1s on ThunderX2 arm64 server. > > > > > > [1] https://github.com/kata-containers/runtime/issues/1917 > > > > > > Reported-by: Ning Bo <n.b at live.com> > > > Signed-off-by: Jia He <justin.he at arm.com> > > > --- > > > drivers/vhost/vsock....

...ggested by Stefano Garzarella, this fixes it by additional kicking the > send_pkt worker in vhost_vsock_start once the virtio device is started. This > makes the pending pkt sent again. > > After this patch, kata-runtime (with vsock enabled) boot time is reduced > from 3s to 1s on a ThunderX2 arm64 server. > > [1] https://github.com/kata-containers/runtime/issues/1917 > > Reported-by: Ning Bo <n.b at live.com> > Suggested-by: Stefano Garzarella <sgarzare at redhat.com> > Signed-off-by: Jia He <justin.he at arm.com> > --- > v2: new solution sug...

From: Jia He <justin.he at arm.com> Date: Sat, 30 May 2020 09:38:28 +0800 > When client on the host tries to connect(SOCK_STREAM, O_NONBLOCK) to the > server on the guest, there will be a panic on a ThunderX2 (armv8a server): ... > The race condition is as follows: > Task1 Task2 > ===== ===== > __sock_release virtio_transport_recv_pkt > __vsock_release vsock_find_bound_socket (found...

Hi Jia, thanks for the patch! I have some comments. On Fri, May 29, 2020 at 09:31:23PM +0800, Jia He wrote: > When client tries to connect(SOCK_STREAM) the server in the guest with NONBLOCK > mode, there will be a panic on a ThunderX2 (armv8a server): > [ 463.718844][ T5040] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 > [ 463.718848][ T5040] Mem abort info: > [ 463.718849][ T5040] ESR = 0x96000044 > [ 463.718852][ T5040] EC = 0x25: DABT (current EL), IL = 32 bits >...

On Fri, May 29, 2020 at 11:21:02PM +0800, Jia He wrote: > When client tries to connect(SOCK_STREAM) the server in the guest with > NONBLOCK mode, there will be a panic on a ThunderX2 (armv8a server): > [ 463.718844][ T5040] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 > [ 463.718848][ T5040] Mem abort info: > [ 463.718849][ T5040] ESR = 0x96000044 > [ 463.718852][ T5040] EC = 0x25: DABT (current EL), IL = 32 bits >...

...> > This fixes it by checking vq->private_data in vhost_transport_send_pkt, > and return at once if !vq->private_data. This makes user connect() > be returned with ECONNREFUSED. > > After this patch, kata-runtime (with vsock enabled) boottime reduces from > 3s to 1s on ThunderX2 arm64 server. > > [1] https://github.com/kata-containers/runtime/issues/1917 > > Reported-by: Ning Bo <n.b at live.com> > Signed-off-by: Jia He <justin.he at arm.com> > --- > drivers/vhost/vsock.c | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff...

...rt_send_pkt, > > > > and return at once if !vq->private_data. This makes user connect() > > > > be returned with ECONNREFUSED. > > > > > > > > After this patch, kata-runtime (with vsock enabled) boottime reduces from > > > > 3s to 1s on ThunderX2 arm64 server. > > > > > > > > [1] https://github.com/kata-containers/runtime/issues/1917 > > > > > > > > Reported-by: Ning Bo <n.b at live.com> > > > > Signed-off-by: Jia He <justin.he at arm.com> > > > > --- > &...

On Tue, Nov 27, 2018 at 05:55:20PM +0000, Jean-Philippe Brucker wrote: > On 23/11/2018 21:56, Michael S. Tsirkin wrote: > >> +config VIRTIO_IOMMU > >> + bool "Virtio IOMMU driver" > >> + depends on VIRTIO=y > >> + select IOMMU_API > >> + select INTERVAL_TREE > >> + select ARM_DMA_USE_IOMMU if ARM > >> + help > >>

...k this is where performance matters the most. To get a feel of the > advantage we get with virtio-iommu, I compared the vSMMU page-table > sharing implementation [2] and vhost-iommu + VFIO with page table > sharing (based on Tomasz Nowicki's vhost-iommu prototype). That's on a > ThunderX2 with a 10Gb NIC assigned to the guest kernel, which > corresponds to case (2) above, with nesting page tables and without the > lazy mode. The host's only job is forwarding invalidation to the HW SMMU. > > vhost-iommu performed on average 1.8x and 5.5x better than vSMMU on > net...

...est to host. I think this is where performance matters the most. To get a feel of the advantage we get with virtio-iommu, I compared the vSMMU page-table sharing implementation [2] and vhost-iommu + VFIO with page table sharing (based on Tomasz Nowicki's vhost-iommu prototype). That's on a ThunderX2 with a 10Gb NIC assigned to the guest kernel, which corresponds to case (2) above, with nesting page tables and without the lazy mode. The host's only job is forwarding invalidation to the HW SMMU. vhost-iommu performed on average 1.8x and 5.5x better than vSMMU on netperf TCP_STREAM and TCP_M...

...ers the most. To get a feel of the >>> advantage we get with virtio-iommu, I compared the vSMMU page-table >>> sharing implementation [2] and vhost-iommu + VFIO with page table >>> sharing (based on Tomasz Nowicki's vhost-iommu prototype). That's on a >>> ThunderX2 with a 10Gb NIC assigned to the guest kernel, which >>> corresponds to case (2) above, with nesting page tables and without the >>> lazy mode. The host's only job is forwarding invalidation to the HW SMMU. >>> >>> vhost-iommu performed on average 1.8x and 5.5...

...performance matters the most. To get a feel of the >> advantage we get with virtio-iommu, I compared the vSMMU page-table >> sharing implementation [2] and vhost-iommu + VFIO with page table >> sharing (based on Tomasz Nowicki's vhost-iommu prototype). That's on a >> ThunderX2 with a 10Gb NIC assigned to the guest kernel, which >> corresponds to case (2) above, with nesting page tables and without the >> lazy mode. The host's only job is forwarding invalidation to the HW SMMU. >> >> vhost-iommu performed on average 1.8x and 5.5x better than vS...