[Bug 2245459] Please upgrade perl-DBIx-SearchBuilder to >= 1.77
https://bugzilla.redhat.com/show_bug.cgi?id=2245459 Fedora Update System changed: What|Removed |Added Status|NEW |MODIFIED --- Comment #1 from Fedora Update System --- FEDORA-2023-9b11fad773 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2023-9b11fad773 -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2245459 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202245459%23c1 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2245494] New: mod_perl-2.0.13 is available
https://bugzilla.redhat.com/show_bug.cgi?id=2245494 Bug ID: 2245494 Summary: mod_perl-2.0.13 is available Product: Fedora Version: rawhide Status: NEW Component: mod_perl Keywords: FutureFeature, Triaged Assignee: zonexpertconsult...@outlook.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: jor...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com, zonexpertconsult...@outlook.com Target Milestone: --- Classification: Fedora Releases retrieved: 2.0.13 Upstream release that is considered latest: 2.0.13 Current version/release in rawhide: 2.0.12-9.fc39 URL: http://search.cpan.org/dist/mod_perl/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from Anitya: https://release-monitoring.org/project/1998/ To change the monitoring settings for the project, please visit: https://src.fedoraproject.org/rpms/mod_perl -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2245494 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202245494%23c0 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora Linux 39 Final blocker status summary #3
On Fri, Oct 20, 2023, 16:56 Adam Williamson wrote: > We're still kinda kicking around ideas for "fixing" this, but I think > if push comes to shove, we'll wind up revoting or waiving it as not > practically fixable. How about something of the form of an ExecStartPre expression (or script) that tests the date and if less than then (say) 2023-01-01 sets the date to the expected release date of F39 (via timedatectl)? Not quite right, but it would likely pass the gpg tests It can (hopefully) be replaced by something better in the future. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Analysis of the overhead of frame pointers on gcc compiles
On Sat, Oct 21, 2023 at 12:35:30PM -0700, John Reiser wrote: > Because of the impact of data cache performance, it is important to > state the CPU, RAM, and cache characteristics when measuring performance. > Such as: the beginning of /proc/cpuinfo: I ran the tests a number of times to attempt to eliminate cache effects, but here are those details: processor: 0 vendor_id: AuthenticAMD cpu family : 25 model : 97 model name : AMD Ryzen 9 7950X 16-Core Processor stepping : 2 microcode : 0xa601203 cpu MHz : 4500.000 cache size : 1024 KB physical id : 0 siblings : 32 core id: 0 cpu cores : 16 apicid : 0 initial apicid : 0 fpu: yes fpu_exception : yes cpuid level: 16 wp : yes flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good amd_lbr_v2 nopl nonstop_tsc cpuid extd_apicid aperfmperf rapl pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpb cat_l3 cdp_l3 hw_pstate ssbd mba perfmon_v2 ibrs ibpb stibp ibrs_enhanced vmmcall fsgsbase bmi1 avx2 smep bmi2 erms invpcid cqm rdt_a avx512f avx512dq rdseed adx smap avx512ifma clflushopt clwb avx512cd sha_ni avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local avx512_bf16 clzero irperf xsaveerptr rdpru wbnoinvd cppc arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif x2avic v_spec_ctrl avx512vbmi umip pku ospke avx512_vbmi2 gfni vaes vpclmulqdq avx512_vnni avx512_bitalg avx512_vpopcntdq rdpid overflow_recov succor smca fsrm flush_l1d bugs : sysret_ss_attrs spectre_v1 spectre_v2 spec_store_bypass bogomips : 8999.55 TLB size : 3584 4K pages clflush size : 64 cache_alignment: 64 address sizes : 48 bits physical, 48 bits virtual power management: ts ttp tm hwpstate cpb eff_freq_ro [13] [14] As it's a completely standand 7950X you can look up the rest. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com nbdkit - Flexible, fast NBD server with plugins https://gitlab.com/nbdkit/nbdkit ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Analysis of the overhead of frame pointers on gcc compiles
On Sat, Oct 21, 2023 at 12:35:30PM -0700, John Reiser wrote: > On 10/20/23 13:23, Richard W.M. Jones wrote: > >Today I've read (twice) that the overhead of frame pointers on the > >runtime of the compiler, GCC, is 10%. This number is nonsense. The > >actual overhead is 1%, and I have done the tests that show this. > > Both the 1% and the 10% results can be valid. In particular, I have seen > variance of up to 15% in CPU time for consecutive runs of the same CPU- > saturating task on the SAME physical machine, due to the lack in Linux of > cache coloring considerations when allocating physical page frames for > virtual memory, and the resulting random affects on the performance > of the data cache. See https://en.wikipedia.org/wiki/Cache_coloring : Can you show an actual, reproducible test to prove your point? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Analysis of the overhead of frame pointers on gcc compiles
On 10/20/23 13:23, Richard W.M. Jones wrote: Today I've read (twice) that the overhead of frame pointers on the runtime of the compiler, GCC, is 10%. This number is nonsense. The actual overhead is 1%, and I have done the tests that show this. Both the 1% and the 10% results can be valid. In particular, I have seen variance of up to 15% in CPU time for consecutive runs of the same CPU- saturating task on the SAME physical machine, due to the lack in Linux of cache coloring considerations when allocating physical page frames for virtual memory, and the resulting random affects on the performance of the data cache. See https://en.wikipedia.org/wiki/Cache_coloring : A virtual memory subsystem that lacks cache coloring is less deterministic with regards to cache performance, as differences in page allocation from one program run to the next can lead to large differences in program performance Page coloring is employed in operating systems such as Solaris, FreeBSD, NetBSD and Windows NT. [Note the conspicuous absence of Linux from that list.] Other sources of real-time contention should be considered, too. Queuing delays in a file system due to encryption, journaling, block allocation and placement, etc., might mask real-time measurement of CPU+cache. Any potentially-competing activity such as graphical desktop environment, use of network or video or audio, or crontab or tasks controlled by systemd, should be minimized. It may be best to measure when the machine has been booted to single-user mode. Because of the impact of data cache performance, it is important to state the CPU, RAM, and cache characteristics when measuring performance. Such as: the beginning of /proc/cpuinfo: processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 94 model name : Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz stepping: 3 microcode : 0xf0 cpu MHz : 3418.725 cache size : 6144 KB physical id : 0 siblings: 4 core id : 0 cpu cores : 4 On Intel x86_64 Core CPUs with hyperthreading, then the two threads per core compete for the 256KiB L2 cache per core. On x86_64, then the CPUID instruction reports cache organization, which can be interpreted, such as: 22 GenuineIntel TLB/Cache: eax=76036301 ebx=00f0b6ff ecx= edx=00c3 1 repeat for more info 63 03 dTLB: 4 KByte pages, 4-way, 64 entries 76 iTLB: 2M/4M pages, fully associative, 8 entries ff Use CPUID leaf 4 b6 f0 64-byte prefetching c3 Cache: eax=1c004121 ebx=01c0003f ecx=003f edx= 1 Data Cache 1 Cache Level (starts at 1) 1 Self-initializing 0 Fully associative 2 max # logical processors 8 max # physical cores 64 system coherency line size 1 physical line partitions 8 ways of associativity 64 number of sets 32768 total size 0 WBINVD/INVD acts on this level only 0 cache includes lower levels 0 complex cache indexing Cache: eax=1c004122 ebx=01c0003f ecx=003f edx= 2 Instruction Cache 1 Cache Level (starts at 1) 1 Self-initializing 0 Fully associative 2 max # logical processors 8 max # physical cores 64 system coherency line size 1 physical line partitions 8 ways of associativity 64 number of sets 32768 total size 0 WBINVD/INVD acts on this level only 0 cache includes lower levels 0 complex cache indexing Cache: eax=1c004143 ebx=00c0003f ecx=03ff edx= 3 Unified Cache 2 Cache Level (starts at 1) 1 Self-initializing 0 Fully associative 2 max # logical processors 8 max # physical cores 64 system coherency line size 1 physical line partitions 4 ways of associativity 1024 number of sets 262144 total size 0 WBINVD/INVD acts on this level only 0 cache includes lower levels 0 complex cache indexing Cache: eax=1c03c163 ebx=02c0003f ecx=1fff edx=0006 3 Unified Cache 3 Cache Level (starts at 1) 1 Self-initializing 0 Fully associative 16 max # logical processors 8 max # physical cores 64 system coherency line size 1 physical line partitions 12 ways of associativity 8192 number of sets 6291456 total size 0 WBINVD/INVD acts on this level only 1 cache includes lower levels 1 complex cache indexing Cache: eax= ebx= ecx= edx= ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2245459] New: Please upgrade perl-DBIx-SearchBuilder to >= 1.77
https://bugzilla.redhat.com/show_bug.cgi?id=2245459 Bug ID: 2245459 Summary: Please upgrade perl-DBIx-SearchBuilder to >= 1.77 Product: Fedora Version: 38 OS: Linux Status: NEW Component: perl-DBIx-SearchBuilder Severity: medium Assignee: rc040...@freenet.de Reporter: rc040...@freenet.de QA Contact: extras...@fedoraproject.org CC: lxt...@gmail.com, perl-devel@lists.fedoraproject.org, rc040...@freenet.de Target Milestone: --- Classification: Fedora Please upgrade perl-DBIx-SearchBuilder to >= 1.77 on all released Fedoras. perl-DBIx-SearchBuilder >= 1.77 is a prerequistite of rt-5.0.5, which is supposed to fix two yet undisclosed CVEs on older versions of rt. Reproducible: Always -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2245459 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202245459%23c0 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora Linux 39 Final blocker status summary #3
On Sat, Oct 21, 2023 at 4:08 PM Chris Adams wrote: > Certainly - I was just looking for a more general solution to non-RTC > systems going forward. Ideally, there could be something triggered by a > lack of an RTC, but it looks like systemd path units cannot work based > on a path (e.g. /dev/rtc) _not_ existing. That's unfortunate, that > would make it easy. I believe negation works (not tested) as in: ConditionPathExists=!/dev/rtc ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora Linux 39 Final blocker status summary #3
Once upon a time, Gary Buhrmaster said: > Personally, I have been using systemd-timesyncd for > quite some time on the vast majority of my systems > and am quite satisfied with it, but I believe that > changing from chrony to systemd-timesyncd was > considered too big of a last minute change since > we are in the final blocker stage of a release. Certainly - I was just looking for a more general solution to non-RTC systems going forward. Ideally, there could be something triggered by a lack of an RTC, but it looks like systemd path units cannot work based on a path (e.g. /dev/rtc) _not_ existing. That's unfortunate, that would make it easy. -- Chris Adams ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
[Bug 2241969] Please branch and build perl-Mail-Box in epel9
https://bugzilla.redhat.com/show_bug.cgi?id=2241969 --- Comment #10 from Michael J Gruber --- Uh, yes, the dreaded crb. I knew it has devel (i.e. BRs) for split libs but forgot that even carries requires of EPEL packages, but does not get enabled when EPEL is. I should have know since the majority of my EPEL woes comes from the existence of CRB. It keeps us from putting stuff into EPEL which we need, but then it's not there when needed. Oh well. Anyways, thanks again. Notmuch installs on RHEL9 with EPEL (testing, for now) plus CRB now. -- You are receiving this mail because: You are on the CC list for the bug. https://bugzilla.redhat.com/show_bug.cgi?id=2241969 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla=report-spam_desc=Report%20of%20Bug%202241969%23c10 ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora Linux 39 Final blocker status summary #3
On Sat, Oct 21, 2023 at 8:12 AM Adam Williamson wrote: > > On Sat, 2023-10-21 at 11:34 +0200, Tomasz Torcz wrote: > > On Fri, Oct 20, 2023 at 08:40:43PM -0500, Chris Adams wrote: > > > Once upon a time, Adam Williamson said: > > > > 6. distribution - https://bugzilla.redhat.com/2242759 - NEW > > > > dnf system-upgrade fails on some RPi4 due to system boot date that pre- > > > > dates gpg key > > > > > > > > We're still kinda kicking around ideas for "fixing" this, but I think > > > > if push comes to shove, we'll wind up revoting or waiving it as not > > > > practically fixable. > > > > > > Not adding to the ticket (because "me too" is not useful there), but... > > > I think Fedora should include SOME type of "fake hwclock"-type thing for > > > systems with no RTC (make a systemd service depend on /dev/rtc not > > > existing?), as other RPi-targeted distros do. This isn't RPi-specific, > > > a number of the small boards have no RTC. I do typically add an RTC to > > > my Pis, but not always (for various reasons). > > > > We already have systemd-timesyncd. On startup, it syncs the time to > > the mtime of: > > - /var/lib/systemd/timesync/clock file; or > > - /usr/lib/clock-epoch file; or > > - a time derived from the source tree at build time > > > > timesyncd is mentioned in the bug, but I didn't read everything. > > There are several ways we could certainly address the bug going > forward. Say, starting with a Fedora 40 Change. But it seems less clear > how we could safely fix it for upgrades from F37 or F38 to F39, without > pushing a level of change that is inappropriate for a stable release. Could we initialize the time with the timestamp of the initrd and then update the timestamp to the current time after that? That should work around this specific problem, I think? -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Upgrades of Sundials and PETSc
On 20-10-2023 15:52, Ben Beasley wrote:
For next time, this seems to work for me:
for p in petsc{,64,-openmpi,-mpich} libpetsc.so; do repoquery -q
--repo=rawhide{,-source} --whatrequires "$p"; done | sort -u
An alternative to above, using gotmax23's excellent fedrq [1], you'd get
the same result with a oneliner:
$ fedrq wr -s petsc*
bout++-5.0.0-11.fc40.src
dolfin-2019.1.0.post0-47.fc40.src
freefem++-4.13-6.fc40.src
getdp-3.5.0-9.fc40.src
python-steps-3.6.0-30.fc39.src
sundials-6.6.1-3.fc40.src
[1] https://fedrq.gtmx.me
-- Sandro
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora Linux 39 Final blocker status summary #3
On Sat, 2023-10-21 at 11:34 +0200, Tomasz Torcz wrote: > On Fri, Oct 20, 2023 at 08:40:43PM -0500, Chris Adams wrote: > > Once upon a time, Adam Williamson said: > > > 6. distribution - https://bugzilla.redhat.com/2242759 - NEW > > > dnf system-upgrade fails on some RPi4 due to system boot date that pre- > > > dates gpg key > > > > > > We're still kinda kicking around ideas for "fixing" this, but I think > > > if push comes to shove, we'll wind up revoting or waiving it as not > > > practically fixable. > > > > Not adding to the ticket (because "me too" is not useful there), but... > > I think Fedora should include SOME type of "fake hwclock"-type thing for > > systems with no RTC (make a systemd service depend on /dev/rtc not > > existing?), as other RPi-targeted distros do. This isn't RPi-specific, > > a number of the small boards have no RTC. I do typically add an RTC to > > my Pis, but not always (for various reasons). > > We already have systemd-timesyncd. On startup, it syncs the time to > the mtime of: > - /var/lib/systemd/timesync/clock file; or > - /usr/lib/clock-epoch file; or > - a time derived from the source tree at build time > > timesyncd is mentioned in the bug, but I didn't read everything. There are several ways we could certainly address the bug going forward. Say, starting with a Fedora 40 Change. But it seems less clear how we could safely fix it for upgrades from F37 or F38 to F39, without pushing a level of change that is inappropriate for a stable release. -- Adam Williamson (he/him/his) Fedora QA Fedora Chat: @adamwill:fedora.im | Mastodon: @ad...@fosstodon.org https://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora Linux 39 Final blocker status summary #3
On Sat, Oct 21, 2023 at 9:35 AM Tomasz Torcz wrote: > We already have systemd-timesyncd. On startup, it syncs the time to > the mtime of: > - /var/lib/systemd/timesync/clock file; or > - /usr/lib/clock-epoch file; or > - a time derived from the source tree at build time > > timesyncd is mentioned in the bug, but I didn't read everything. Personally, I have been using systemd-timesyncd for quite some time on the vast majority of my systems and am quite satisfied with it, but I believe that changing from chrony to systemd-timesyncd was considered too big of a last minute change since we are in the final blocker stage of a release. I believe that a change proposal (for F40) to change to systemd-timesyncd, or fake-hwclock (or some other agreed upon solution) by default should be created so the non-RTC systems will work properly at future upgrades (converting existing systems from chrony to systemd-timesyncd can be complicated if the systems has modified the default chrony config or is not a (pure) client, so that may only be a longer term fix). ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Whole system analysis with frame pointers
I was asked about the topic in the subject, and I think it's not very well known. The news is that since Fedora 38, whole system performance analysis is now easy to do. This can be used to identify hot spots in single applications, or what the (whole computer) is really doing during lengthy operations. You can visualise these in various ways - my favourite is Brendan Gregg's Flame Graphs tools, but perf has many alternate ways to capture and display the data: https://www.brendangregg.com/linuxperf.html https://www.brendangregg.com/flamegraphs.html https://perf.wiki.kernel.org/index.php/Tutorial I did a 15 min talk on this topic, actually to an internal Red Hat audience, but I guess it's fine to open it up to everyone: http://oirase.annexia.org/tmp/2023-03-08-flamegraphs.mp4 [57M, 15m41s] To show the kind of thing which is possible I have captured three whole system flame graphs. First comes from doing "make -j32" in the qemu build tree: http://oirase.annexia.org/tmp/2023-gcc-with-lto.svg 8% of the time is spent running the assembler. I seem to recall that Clang uses a different approach of integrating the assembler into the compiler and I guess it probably avoids most of that overhead. The second is an rpmbuild of the Fedora Rawhide kernel package: http://oirase.annexia.org/tmp/2023-kernel-build.svg I think it's interesting that 6% of the time is spent compressing the RPMs, and another 6% running pahole (debuginfo generation?) But the most surprising thing is it appears 42% of the time is spent just parsing C code [if I'm reading that right, I actually can't believe parsing takes so much time]. If true there must be opportunities to optimize things here. Captures work across userspace and kernel code, as shown in the third example which is a KVM (ie. hardware assisted) virtual machine doing some highly parallel work inside: http://oirase.annexia.org/tmp/2023-kvm-build.svg You can clearly see the 8 virtual (guest) CPUs on the left side, using KVM. More interesting is that this guest uses a qcow2 file for disk and there's a heck of an overhead writing to that file. There's nothing to fix here -- qcow2 files shouldn't be used in this situation; for best performance it would be better to use a local block device to back the guest. The overhead of frame pointers in my measurements is about 1%, so this enhanced visibility into the system seems well worthwhile. I use this all the time. This year I've used it to suggest optimizations in qemu, nbdkit and the kernel. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Fedora Linux 39 Final blocker status summary #3
On Fri, Oct 20, 2023 at 08:40:43PM -0500, Chris Adams wrote: > Once upon a time, Adam Williamson said: > > 6. distribution - https://bugzilla.redhat.com/2242759 - NEW > > dnf system-upgrade fails on some RPi4 due to system boot date that pre- > > dates gpg key > > > > We're still kinda kicking around ideas for "fixing" this, but I think > > if push comes to shove, we'll wind up revoting or waiving it as not > > practically fixable. > > Not adding to the ticket (because "me too" is not useful there), but... > I think Fedora should include SOME type of "fake hwclock"-type thing for > systems with no RTC (make a systemd service depend on /dev/rtc not > existing?), as other RPi-targeted distros do. This isn't RPi-specific, > a number of the small boards have no RTC. I do typically add an RTC to > my Pis, but not always (for various reasons). We already have systemd-timesyncd. On startup, it syncs the time to the mtime of: - /var/lib/systemd/timesync/clock file; or - /usr/lib/clock-epoch file; or - a time derived from the source tree at build time timesyncd is mentioned in the bug, but I didn't read everything. -- Tomasz Torcz There exists no separation between gods and men: to...@pipebreaker.pl one blends softly casual into the other. — Frank Herbert ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
