search for: virtx

...th the register allocator :\ > > You may wan't to investigate how RAGreedy::canEvictInterference() is > behaving. > Ok, this is what I've noticed, not sure if it makes sense at all but, regalloc fails with the following sequence: 1) directly assign the physreg in PTR RC to a virtX. 2) for a virtY which also belongs to the PTR RC, try to evict: call canEvictInterference() for virtY which interferes with virtX, returns true. evict and unassign virtX and assign physreg to virtY. 3) for a virtZ which also belongs to the PTR RC, try to evict: call canEvictInterference() for virtZ...

On Dec 17, 2012, at 8:38 AM, Borja Ferrer <borja.ferav at gmail.com> wrote: > Hello, > > I'm getting the "LLVM ERROR: ran out of registers during register allocation" error message for an out of tree target I'm developing. This is happening for the following piece of C code: > > struct ss > { > int a; > int b; > int c; > }; > void

...>> You may wan't to investigate how RAGreedy::canEvictInterference() is >> behaving. >> > > Ok, this is what I've noticed, not sure if it makes sense at all but, > regalloc fails with the following sequence: > > 1) directly assign the physreg in PTR RC to a virtX. > 2) for a virtY which also belongs to the PTR RC, try to evict: call > canEvictInterference() for virtY which interferes with virtX, returns true. > evict and unassign virtX and assign physreg to virtY. > 3) for a virtZ which also belongs to the PTR RC, try to evict: call > canEvic...

Hello, I'm getting the "LLVM ERROR: ran out of registers during register allocation" error message for an out of tree target I'm developing. This is happening for the following piece of C code: struct ss { int a; int b; int c; }; void loop(struct ss *x, struct ss **y, int z) { int i; for (i=0; i<z; ++i) { x->c += y[i]->b; } } The problem relies in

...U) and I started fio AFTER that. OK, that's different, we should not be triggering a warning for that. What does your machine/virtblk topology look like in terms of CPUS, nr of queues for virtblk, etc? You can probably get this info the easiest by just doing a: # find /sys/kernel/debug/block/virtX replace virtX with your virtblk device name. Generate this info both before and after the hotplug event. >> While it's a bit annoying that we trigger the WARN_ON() for a condition >> that can happen, we're basically interested in it if it triggers for >> normal operation...

On 11/20/2017 08:42 PM, Jens Axboe wrote: > On 11/20/2017 12:29 PM, Christian Borntraeger wrote: >> >> >> On 11/20/2017 08:20 PM, Bart Van Assche wrote: >>> On Fri, 2017-11-17 at 15:42 +0100, Christian Borntraeger wrote: >>>> This is >>>> >>>> b7a71e66d (Jens Axboe 2017-08-01 09:28:24 -0600 1141) * are mapped to

On 11/20/2017 08:42 PM, Jens Axboe wrote: > On 11/20/2017 12:29 PM, Christian Borntraeger wrote: >> >> >> On 11/20/2017 08:20 PM, Bart Van Assche wrote: >>> On Fri, 2017-11-17 at 15:42 +0100, Christian Borntraeger wrote: >>>> This is >>>> >>>> b7a71e66d (Jens Axboe 2017-08-01 09:28:24 -0600 1141) * are mapped to

...version, but never observed a "Domain-unnamed". Any idea how to resolve this issue would be highly appreciated, as working live-migration is crucial to us. Regards, Thomas Weyergraf Some notes on our config: 1. We still use xm/xend for various reasons ---- 2. Our grub-config for the virtx-hosts is as follows: ---- default=0 timeout=5 #splashimage=(hd0,0)/grub/splash.xpm.gz #hiddenmenu title CentOS (xen-4.2.5-37.el6.gz vmlinuz-3.10.56-11.el6.centos.alt.x86_64) root (hd0,0) kernel /xen-4.2.5-37.el6.gz iommu=1 console=vga,com1 com1=115200,8n1 vga=text-80x25 dom0_mem=...

...ggering a warning for that. > What does your machine/virtblk topology look like in terms of CPUS, > nr of queues for virtblk, etc? FWIW, 4.11 does work, 4.12 and later is broken. > > You can probably get this info the easiest by just doing a: > > # find /sys/kernel/debug/block/virtX > > replace virtX with your virtblk device name. Generate this info both > before and after the hotplug event. It happens in all variants (1 cpu to 2 or 16 to 17 and independent of the number of disks). What I can see is that the block layer does not yet sees the new CPU: [root at zhyp...

...ggering a warning for that. > What does your machine/virtblk topology look like in terms of CPUS, > nr of queues for virtblk, etc? FWIW, 4.11 does work, 4.12 and later is broken. > > You can probably get this info the easiest by just doing a: > > # find /sys/kernel/debug/block/virtX > > replace virtX with your virtblk device name. Generate this info both > before and after the hotplug event. It happens in all variants (1 cpu to 2 or 16 to 17 and independent of the number of disks). What I can see is that the block layer does not yet sees the new CPU: [root at zhyp...