> Hello Kamil, > > Sorry for replying late. I subscribed to this list, but for a reason the > emails are still not being delivered to me. I clicked on some more buttons > in the interface right now, so we'll see. In the mean time, I am using the > web interface to reply, so please forgive the awkward formatting that might > come out of this.
Hello Dodji, welcome. > I think the test systems must have that kind of amount of memory. For most > packages, the memory consumption is reasonable. But for some packages where > the combination of ELF binary size and uncompressed debug info size is big, > then, well, the tool is going to require a lot of memory. For instance, it > takes 13+GB of memory to compare the ABI of two instances of the libjvm.so > library. I've read the backlog of your discussion with tflink, but I'm not sure what the conclusion is. I believe we can't assign 15GB RAM to all our test VMs (and we can't tie a specific task to a specific set of VMs at the moment). So I guess we will increase our test VMs memory to some "reasonable" amount and let the few extremely large packages crash with OOM. (That reminds me we should make sure to disable swap in VMs, otherwise that would kill the host). Do you have any advice what this "reasonable" amount of RAM should be? 4 GB? 6 GB? So that 95% of tasks work OK, and just the extreme ones crash. We can then add those to a blacklist. Speaking of lists, you and Tim were mentioning white/blacklists, also critpath set. So what is the ideal set of packages we should run on initially? All packages? Only critpath packages? Only libraries included in critpath? In case we should run just on libraries, any good recommendation how to recognize that (better than matching "lib*" in package name)? We would need to make the decision without downloading the package, but I guess we could query koji or repo metadata if necessary. We will need to implement white/blacklisting, ideally I'd like you to have the control over it, not us (so e.g. defining that in task.yaml formula). We can probably implement critpath support (recognizing what is in critpath and what is not), I'm sure it will be needed in other tasks in the future as well. Kamil _______________________________________________ qa-devel mailing list qa-devel@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/qa-devel@lists.fedoraproject.org
