similar to: the naming convention libvirt names a block based storage volume

During concurrent 80 VM creation, each VM takes two network connections, libvirtd failed to respond. Neither restart libvirtd nor restart CIMOM helped. There were 152 vnet bridges found on this RHEL KVM host. After all the vnet bridges were manually removed, libvirtd responded normally again. Is there a known issue about the number limit of vnet bridges regarding libvirtd? Thank you. --Yih

On Tue Nov 17, 2020 at 6:37 PM GMT, Min-Yih Hsu wrote: > Just trying to understand: Are you suggesting a way to have a “-O0” > build without all the debug information? > Exactly.

Its awesome to see so much progress on this! A very minor question - why is it called M680x0 and not M68K given that's what the target arch/triple is and how its usually referred to? Sorry for the bikeshedding.... Simon. On 30/09/2020 21:14, Min-Yih Hsu via llvm-dev wrote: > Hi All, > > I've composed a draft roadmap for this new target. I've decided to try >

Hi All, Just a quick update on the Motorola 6800 backend: Based on the feedback, "M68k" (with lowercase "k") will now be the canonical target name and "m68k" be the target triple name. I've updated all the patches under review to reflect this change. I'm also asking for everyone's help to review all the patches. /* Target independent changes */ 1.

Hi, Thanks for the input. In my ptr_test.O1.ll, the two loops should fall into the last case due to loop rotations. And I think we should handle that case. I propose to check the dominance relation between loop predecessor blocks of the two loops if there is no dominance relation between their loop headers just like case three. The only thing I'm not pretty sure is that is there guarantee to

Dear R Users, When using zeroinfl() function to fit a Zero-Inflated Negative Binomial (ZINB) model to a dataset, the summary() gives an estimate of log(theta) and its standard error, z-value and Pr(>|z|) for the count component. Additionally, it also provided an estimate of Theta, which I believe is the exp(estimate of log(theta)). However, if I would like to have an standard error of Theta

On Wed, 9 Sep 2020 at 18:15, Min-Yih Hsu via llvm-dev < llvm-dev at lists.llvm.org> wrote: > David mentioned in D87337 that LLVM has used similar techniques on code > size (not sure what he was referencing, my guess will be something related > to hot-cold code splitting). > IIUC, it's just using optsize instead of optnone. The idea is that, if the code really doesn't

Hi, I had a VM running on c3rh2 under 'vmc' user: [vmc at c3rh2 .ssh]$ virsh list --all Id Name State ---------------------------------------------------- 1 vs2relocate_nonRoot running After the virsh migration command, "virsh migrate --live --unsafe vs2relocate_nonRoot qemu+ssh://vmc at c3rh1.kirkland.ibm.com/session", this VM

I like Tante Maja. I will call them and see if we can flood them. ;-) I suggest dinner at 18:00? Best, Tobias On Sun, Mar 26, 2017, at 04:08 PM, Bekket McClane via llvm-dev wrote: > Hi, I’m one of the poster session authors, I’m also currently in > Saarbruken > All three places sound nice to me, but I’m not familiar with this town so > maybe you can pick the place? > About the

We would like to propose a new feature to disable optimizations on IR Functions that are considered “cold” by PGO profiles. The primary goal for this work is to improve code optimization speed (which also improves compilation and LTO speed) without making too much impact on target code performance. The mechanism is pretty simple: In the second phase (i.e. optimization phase) of PGO, we would add

Hello, We use PGO to optimize clang itself. I can see if I have time to give this patch some testing. Anything special to look out for except compile benchmark and time to build clang, do you expect any changes in code size? On Wed, Sep 9, 2020, 10:03 Renato Golin via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Wed, 9 Sep 2020 at 01:21, Min-Yih Hsu via llvm-dev < >

On Wed, Sep 9, 2020 at 9:23 PM Wenlei He via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I think calling PGSO size opt is probably a bit misleading though. It’s > more of an adaptive opt strategy, and it can improve performance too due to > better locality. We have something similar internally for selecting opt > level based on profile hotness too under AutoFDO. > >

Hi all, Apparently some people had trouble joining today. I also had trouble using the attendee ID provided by webex. I've canceled the meeting series and will be scheduling a new one with an updated link. Please remember to update your calendars with the new invite. My apologies to those who couldn't join today, and to everyone for the churn. Today's Meeting Minutes:

Hi Min! On 11/3/20 6:10 PM, Min-Yih Hsu wrote: > Showing the prerequisites to become an experimental target and eventually, > an official target. We're currently struggling on setting up the buildbot > but I believe Adrian (CC-ed) is working on that. So I hope the patches can > be sorted out while waiting for the buildbot. The m68k machine is actually already up and running, I

Hello! On 11/3/20 6:10 PM, Min-Yih Hsu wrote: > Just a quick update on the Motorola 6800 backend: Based on the feedback, > "M68k" (with lowercase "k") will now be the canonical target name and > "m68k" be the target triple name. I've updated all the patches under review > to reflect this change. Are there any news on this? The M68k buildbot is ready

Am Di., 17. Nov. 2020 um 12:46 Uhr schrieb Luke Drummond via llvm-dev <llvm-dev at lists.llvm.org>: > > On Tue Nov 17, 2020 at 6:37 PM GMT, Min-Yih Hsu wrote: > > > Just trying to understand: Are you suggesting a way to have a “-O0” > > build without all the debug information? > > > Exactly. What is such a build useful for the average user? If changing the

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I use a dual headed system with one screen on the digital and the other on the analogue ports. Since 7.1 the update the login has switched from the analogue to the digital. This wouldn't be a problem, but I have the digital rotated 90 degrees into a portrait mode. Login is thus best done lying down! Once I've logged in there is no problem,

I’m going to travel with another person, so 2 people in total Cheers, Hsu > Tobias Grosser <tobias.grosser at inf.ethz.ch> 於 2017年3月26日 下午4:16 寫道： > > We have a table reserved at Tante Maja, 18:00 for 15 people. I am travel > with 5 other people, so 10 more spots are open. Please let me know > within 30 minutes if you want a spot, such that I can confirm the >

FYI David is referring to PGSO (profile-guided size optimization) as it exists directly under that name, see: https://reviews.llvm.org/D67120. And yeah using PGSO is selecting optsize while this change is selecting optnone. On 9/9/20, 10:58 AM, "llvm-dev on behalf of Tobias Hieta via llvm-dev" <llvm-dev-bounces at lists.llvm.org<mailto:llvm-dev-bounces at lists.llvm.org> on

On Tue Nov 17, 2020 at 10:35 PM GMT, Michael Kruse wrote: > Am Di., 17. Nov. 2020 um 12:46 Uhr schrieb Luke Drummond via llvm-dev > <llvm-dev at lists.llvm.org>: > > > > On Tue Nov 17, 2020 at 6:37 PM GMT, Min-Yih Hsu wrote: > > > > > Just trying to understand: Are you suggesting a way to have a “-O0” > > > build without all the debug information?