Re: Post 9.1 stable file system problems
On Tue, Jan 01, 2013 at 05:58:06PM +0200, Konstantin Belousov wrote: > On Tue, Jan 01, 2013 at 02:39:44PM +0100, Dominic Fandrey wrote: > > On 01/01/2013 07:51, Konstantin Belousov wrote: > > > On Tue, Jan 01, 2013 at 02:05:11AM +0100, Dominic Fandrey wrote: > > >> On 01/01/2013 01:49, Dominic Fandrey wrote: > > >>> On 01/01/2013 01:29, Chris Rees wrote: > > On 1 Jan 2013 00:01, "Dominic Fandrey" wrote: > > > > > > I have a Tinderbox that I just updated to the current RELENG_9. > > > Following the update build times for packages have increased by a > > > factor between 5 and 20. I.e. I have packages that used to build in > > > 5 minutes and now take an hour. > > > > > > I'm suspecting the file system ever since I saw that the majority of > > > CPU > > > load was caused by ls when I looked at top (more than 2 minutes of CPU > > > time were counted that moment). The majority of the time most of the > > > CPU > > > load is caused by bsdtar, pkg_add, qmake-qt4, etc. Without exception > > > tools that access a lot of files. > > > > > > The file system on which packages are built is nullfs mounted from > > > an async mounted UFS. I turned async off, to no avail. > > > > > > /usr/src/UPDATING says that there were nullfs optimisations. So I > > > think this is where the problem originates. I might hack the > > > tinderbox to > > > use 'ln -s' or set it up for NFS to verify this. > > > > Is your kernel newer than the Jail? The converse causes problems. > > >>> > > >>> I ran makeJail for all jails after updating. > Did you rebuild your modules together with the new kernel ? > > > >>> > > >>> I also seem to have similar problems when building in the host-system. > > >>> The unzip for openjdk-7 has just passed the 11 minutes CPU time mark. > > >>> On my notebook it takes less than 10 seconds. > > >> > > >> Just set WRKOBJDIRPREFIX to a tmpfs on the Tinderbox host system > > >> and the extract takes less than a second. Originally WRKOBJDIRPREFIX > > >> also pointed to a nullfs mount. > > >> > > >> Afterwards I pointed WRKOBJDIRPREFIX to a UFS file system (without > > >> nullfs involvement). The entire make extract took 20s. > > >> > > >> So still faster by at least factor 30 than running it on a nullfs mount > > >> (I eventually SIGINTed so I don't know how long it would've run). > > > > > > Start providing some useful debugging information ? > > > > That one might be interesting. It's all system time: > > > > # time -lh make extract > > ===> License GPLv2 accepted by the user > > ===> Found saved configuration for openjdk-7.9.05_1 > > ===> Extracting for openjdk-7.9.05_2 > > => SHA256 Checksum OK for openjdk-7u6-fcs-src-b24-09_aug_2012.zip. > > => SHA256 Checksum OK for apache-ant-1.8.4-bin.zip. > > ===> openjdk-7.9.05_2 depends on file: /usr/local/bin/unzip - found > > ^Ctime: command terminated abnormally > > 4m29.30s real 3.03s user 4m22.55s sys > > 5008 maximum resident set size > >135 average shared memory size > > 2932 average unshared data size > >127 average unshared stack size > > 7772 page reclaims > > 0 page faults > > 0 swaps > > 19 block input operations > >101 block output operations > > 0 messages sent > > 0 messages received > > 41 signals received > > 1597 voluntary context switches > > 16590 involuntary context switches > > Ok, from your mount -v output, are the three nullfs mounts the only > nullfs mount ever used ? > > Is it only unzip which demostrates the silly behaviour ? Or does it > happen with any program ? E.g., does ls(1) or sha1 on the nullfs mount > also slow ? > > Could you try some low-tech profiling on the slow program. For instance, > you could run ktrace/kdump -R to see which syscalls are slow. > > Most darkly part of your report for me, is that I also use nullfs-backed > jails both on HEAD and stable/9, with bigger scale, and I do not have > an issue. I just did > pooma32% time unzip -q > /usr/local/arch/freebsd/distfiles/openjdk-7u6-fcs-src-b24-09_aug_2012.zip > unzip -q 3.25s user 23.77s system 78% cpu 34.482 total > over nullfs mount of > /usr/home on /usr/sfw/local8/opt/pooma32/usr/home (nullfs, local). > > Please try the following patch, which changes nullfs behaviour to be > non-cached by default. You could turn on the caching with the 'mount -t > nullfs -o cache from to' mounting command. I am interested if use/non-use > of -o cache makes a difference for you. Ping. Any update ? pgptVju7RyzVW.pgp Description: PGP signature
load average 0.60 at 100% idle
Hi! Bare with me here as I'm totally new to FreeBSD (like 2 weeks). >From what I understand, there is a change in FreeBSD 9.1 ACPI code that makes detection of devices happen earlier? This can result in eventtimer irqs being shared with another device and can therefor throw off tools reporting load avg values (they report constantly around 0.60 in load). I guess there were good reasons for making the ACPI change, so is this a ACPI problem or should the code around the tools, such as top, change? This is a 9.1 "regression" as the problem is not there in FreeBSD 9.0. Here's some more info on the bug and possible workarounds: http://www.freebsd.org/cgi/query-pr.cgi?pr=173541&cat= and http://lists.freebsd.org/pipermail/freebsd-stable/2012-April/067382.html Any input on this would be greatly appreciated. Thanks Johan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: load average 0.60 at 100% idle
Cc'ing the committer / ACPI owner! jkim - any comments? Adrian On 5 January 2013 12:38, Johan Broman wrote: > Hi! > > Bare with me here as I'm totally new to FreeBSD (like 2 weeks). > > From what I understand, there is a change in FreeBSD 9.1 ACPI code > that makes detection of devices happen earlier? This can result in > eventtimer irqs being shared with another device and can therefor > throw off tools reporting load avg values (they report constantly > around 0.60 in load). I guess there were good reasons for making the > ACPI change, so is this a ACPI problem or should the code around the > tools, such as top, change? This is a 9.1 "regression" as the problem > is not there in FreeBSD 9.0. > > Here's some more info on the bug and possible workarounds: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=173541&cat= > > and > > http://lists.freebsd.org/pipermail/freebsd-stable/2012-April/067382.html > > Any input on this would be greatly appreciated. > > Thanks > Johan > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
GELI performance on Atom D525
Hi, Can anyone with access to Atom D525 processor can do a performance check for me: # kldload geom_eli # kldload geom_zero # sysctl kern.geom.zero.clear=0 # geli onetime -s 4096 -l 256 -e aes-cbc gzero # dd if=/dev/gzero.eli of=/dev/null bs=1m count=4096 # geli kill gzero # geli onetime -s 4096 -l 256 -e aes-xts gzero # dd if=/dev/gzero.eli of=/dev/null bs=1m count=4096 I'm interested in dd outputs ofcourse. I would like to compare this to VIA Esther processor 1000MHz, which has padlock AES accelerator. My results are: AES-CBC: 4294967296 bytes transferred in 31.805894 secs (135036836 bytes/sec) AES-XTS: 4294967296 bytes transferred in 765.232668 secs (5612629 bytes/sec) Anyone can provide the results for Atom D525? Cheers, Wiktor Niesiobedzki ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: GELI performance on Atom D525
On Sat, Jan 5, 2013 at 4:58 PM, Wiktor Niesiobedzki wrote: > Hi, > > Can anyone with access to Atom D525 processor can do a performance check for > me: > # kldload geom_eli > # kldload geom_zero > # sysctl kern.geom.zero.clear=0 > # geli onetime -s 4096 -l 256 -e aes-cbc gzero > # dd if=/dev/gzero.eli of=/dev/null bs=1m count=4096 > # geli kill gzero > # geli onetime -s 4096 -l 256 -e aes-xts gzero > # dd if=/dev/gzero.eli of=/dev/null bs=1m count=4096 > > I'm interested in dd outputs ofcourse. I would like to compare this to > VIA Esther processor 1000MHz, which has padlock AES accelerator. > > My results are: > > AES-CBC: > 4294967296 bytes transferred in 31.805894 secs (135036836 bytes/sec) > > AES-XTS: > 4294967296 bytes transferred in 765.232668 secs (5612629 bytes/sec) > > > Anyone can provide the results for Atom D525? FreeBSD 9.0-RELEASE-p1 amd64: CPU: Intel(R) Atom(TM) CPU D525 @ 1.80GHz (1800.04-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x106ca Family = 6 Model = 1c Stepping = 10 Features=0xbfebfbff Features2=0x40e31d AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant, performance statistics # sysctl kern.geom.zero.clear=0 kern.geom.zero.clear: 1 -> 0 # geli onetime -s 4096 -l 256 -e aes-cbc gzero # dd if=/dev/gzero.eli of=/dev/null bs=1m count=4096 4096+0 records in 4096+0 records out 4294967296 bytes transferred in 192.024101 secs (22366814 bytes/sec) # geli kill gzero # geli onetime -s 4096 -l 256 -e aes-xts gzero # dd if=/dev/gzero.eli of=/dev/null bs=1m count=4096 4096+0 records in 4096+0 records out 4294967296 bytes transferred in 232.956895 secs (18436747 bytes/sec) - Max ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: GELI performance on Atom D525
On 01/05/2013 22:58, Wiktor Niesiobedzki wrote: Hi, Can anyone with access to Atom D525 processor can do a performance check for me: # kldload geom_eli # kldload geom_zero # sysctl kern.geom.zero.clear=0 # geli onetime -s 4096 -l 256 -e aes-cbc gzero # dd if=/dev/gzero.eli of=/dev/null bs=1m count=4096 # geli kill gzero # geli onetime -s 4096 -l 256 -e aes-xts gzero # dd if=/dev/gzero.eli of=/dev/null bs=1m count=4096 I'm interested in dd outputs ofcourse. I would like to compare this to VIA Esther processor 1000MHz, which has padlock AES accelerator. My results are: AES-CBC: 4294967296 bytes transferred in 31.805894 secs (135036836 bytes/sec) AES-XTS: 4294967296 bytes transferred in 765.232668 secs (5612629 bytes/sec) Anyone can provide the results for Atom D525? FreeBSD 9.1-STABLE (svn 243788) CPU: Intel(R) Atom(TM) CPU D525 @ 1.80GHz (1795.75-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x106ca Family = 0x6 Model = 0x1c Stepping = 10 Features=0xbfebfbff Features2=0x40e31d AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant, performance statistics real memory = 4294967296 (4096 MB) avail memory = 4083802112 (3894 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: <032111 APIC1732> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 HTT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP/HT): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP/HT): APIC ID: 3 # kldload geom_eli # kldload geom_zero # sysctl kern.geom.zero.clear=0 kern.geom.zero.clear: 1 -> 0 # geli onetime -s 4096 -l 256 -e aes-cbc gzero # dd if=/dev/gzero.eli of=/dev/null bs=1m count=4096 4096+0 records in 4096+0 records out 4294967296 bytes transferred in 245.828912 secs (17471368 bytes/sec) # geli kill gzero # geli onetime -s 4096 -l 256 -e aes-xts gzero # dd if=/dev/gzero.eli of=/dev/null bs=1m count=4096 4096+0 records in 4096+0 records out 4294967296 bytes transferred in 291.027184 secs (14757959 bytes/sec) Cheers, Wiktor Niesiobedzki Claude Buisson ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
