Re: ts_to_ct messages; ntp: time correction of -1200 seconds exceeds sanity limit
On Sun, Dec 05, 2010 at 08:30:11PM -0600, James R. Van Artsdalen wrote: FreeBSD gohorns.x 9.0-CURRENT FreeBSD 9.0-CURRENT #1 r216088: Thu Dec 2 23:20:14 CST 2010 r...@gohorns.x:/usr/obj/usr/src/sys/GENERIC amd64 I have been getting a lot of ts_to_ct for months: are we supposed to look for something or report anything about these? They should be silenced. I have this local change for too long, will commit it shortly unless somebody objects: diff --git a/sys/kern/subr_clock.c b/sys/kern/subr_clock.c index 4e7bcd0..c04b5ac 100644 --- a/sys/kern/subr_clock.c +++ b/sys/kern/subr_clock.c @@ -49,7 +49,7 @@ __FBSDID($FreeBSD$); #include sys/sysctl.h #include sys/timetc.h -#define ct_debug bootverbose +static int ct_debug; static int adjkerntz; /* local offset from UTC in seconds */ static int wall_cmos_clock;/* wall CMOS clock assumed if != 0 */ pgpzZ94SynafF.pgp Description: PGP signature
Re: ts_to_ct messages; ntp: time correction of -1200 seconds exceeds sanity limit
On Mon, 6 Dec 2010, Kostik Belousov wrote: On Sun, Dec 05, 2010 at 08:30:11PM -0600, James R. Van Artsdalen wrote: FreeBSD gohorns.x 9.0-CURRENT FreeBSD 9.0-CURRENT #1 r216088: Thu Dec 2 23:20:14 CST 2010 r...@gohorns.x:/usr/obj/usr/src/sys/GENERIC amd64 I have been getting a lot of ts_to_ct for months: are we supposed to look for something or report anything about these? They should be silenced. I have this local change for too long, will commit it shortly unless somebody objects: diff --git a/sys/kern/subr_clock.c b/sys/kern/subr_clock.c index 4e7bcd0..c04b5ac 100644 --- a/sys/kern/subr_clock.c +++ b/sys/kern/subr_clock.c @@ -49,7 +49,7 @@ __FBSDID($FreeBSD$); #include sys/sysctl.h #include sys/timetc.h -#define ct_debug bootverbose +static int ct_debug; static int adjkerntz; /* local offset from UTC in seconds */ static int wall_cmos_clock; /* wall CMOS clock assumed if != 0 */ I have actually been using this one for two months now, which allows you to enable it if you want the debugging. --- sys/kern/subr_clock.c.orig 2010-11-14 16:10:15.0 + +++ sys/kern/subr_clock.c 2010-12-04 23:39:51.0 + @@ -49,7 +49,7 @@ __FBSDID($FreeBSD: src/sys/kern/subr_cl #include sys/sysctl.h #include sys/timetc.h -#define ct_debug bootverbose +static int ct_debug; static int adjkerntz; /* local offset from UTC in seconds */ static int wall_cmos_clock;/* wall CMOS clock assumed if != 0 */ @@ -60,6 +60,8 @@ int tz_dsttime; * This have traditionally been in machdep, but should probably be moved to * kern. */ +SYSCTL_INT(_machdep, OID_AUTO, ct_debug, + CTLFLAG_RW, ct_debug, 0, Print ct debug if enabled.); SYSCTL_INT(_machdep, OID_AUTO, wall_cmos_clock, CTLFLAG_RW, wall_cmos_clock, 0, CMOS clock keeps wall time); -- Bjoern A. Zeeb Welcome a new stage of life. ks Going to jail sucks -- bz All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: In-kernel PPPoE
David Rhodus wrote: Does mpd work in -current ? Last tried I, netgraph had problems with mpd. I have successfully used it on -CURRENT as late as: FreeBSD mini 9.0-CURRENT FreeBSD 9.0-CURRENT #16: Wed Nov 17 07:11:06 SAST 2010 i...@mini:/usr/obj/usr/src/sys/APPLE i386 Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: In-kernel PPPoE
On Mon, 6 Dec 2010, Andriy Gapon wrote: BTW, there is a rumor that mpd may become an 'in source' program too. It comes 'in source';-) I think last time it came up for base, the package ended up being in the dataset of the release packages and I think that's fine enough. I cannot see any advantage having it in base. I could see a lot more advantage with someone picking up the netgraph problem reports and fixing them... /bz -- Bjoern A. Zeeb Welcome a new stage of life. ks Going to jail sucks -- bz All my daemons like it! http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/jails.html ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: binutils problem? WAS [Re: static linking error: ELF binary type 0 not known. Exec format error. Binary file not executable.]
On Sat, Dec 04, 2010 at 12:52:57AM +0100, Dimitry Andric wrote: On 2010-12-03 10:58, Anton Shterenlikht wrote: a.out: ELF 64-bit LSB executable, IA-64, version 1 (SYSV), statically linked, not stripped ... The branding on ia64 is wrong. The executable is not marked as being a FreeBSD executable. It's declared as SYSV, whereas on amd64 it's properly declared as FreeBSD. This is a binutils problem. ... Anybody here can explain better what Marcel means by binutils problem, and how to fix it? I've binutils-2.20.1_3 installed from devel/binutils. The problem is that our base binutils's BFD library has a custom hack to 'brand' the produced executables, e.g. set the ELF_OSABI field in the ELF header to ELFOSABI_FREEBSD. Other arches such as i386, amd64 (x86_64 in binutils land), sparc and even alpha (!) have had patches sent upstream to do the right thing for FreeBSD, but not ia64. If you can, please try the attached patch, which resolves the problem on the ia64 machine I have tried it on. It should really be sent upstream to the binutils people, if there is some interest. Could there be a problem in the patch?: % pwd /usr/src/contrib/binutils/bfd % patch binutils-ia64-freebsd.diff Hmm... Looks like a unified diff to me... The text leading up to this was: -- |diff --git a/bfd/config.bfd b/bfd/config.bfd |index 9b719d8..d2fe23e 100644 |--- a/bfd/config.bfd |+++ b/bfd/config.bfd -- Patching file config.bfd using Plan A... Hunk #1 failed at 182. 1 out of 1 hunks failed--saving rejects to config.bfd.rej Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -- |diff --git a/bfd/configure b/bfd/configure |index 278cc1d..ad9dcc9 100755 |--- a/bfd/configure |+++ b/bfd/configure -- Patching file configure using Plan A... Hunk #1 succeeded at 6365 with fuzz 1 (offset -8804 lines). Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -- |diff --git a/bfd/elfxx-ia64.c b/bfd/elfxx-ia64.c |index d42ad89..5625c44 100644 |--- a/bfd/elfxx-ia64.c |+++ b/bfd/elfxx-ia64.c -- Patching file elfxx-ia64.c using Plan A... Hunk #1 succeeded at 5013 (offset -1064 lines). Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -- |diff --git a/bfd/targets.c b/bfd/targets.c |index 3e99754..a642a8d 100644 |--- a/bfd/targets.c |+++ b/bfd/targets.c -- Patching file targets.c using Plan A... Hunk #1 succeeded at 595 with fuzz 1 (offset -102 lines). Hmm... The next patch looks like a unified diff to me... The text leading up to this was: -- |diff --git a/ld/emulparams/elf64_ia64_fbsd.sh b/ld/emulparams/elf64_ia64_fbsd.sh |index ab7e78f..a7e2675 100644 |--- a/ld/emulparams/elf64_ia64_fbsd.sh |+++ b/ld/emulparams/elf64_ia64_fbsd.sh -- File to patch: ../ld/emulparams/elf64_ia64_fbsd.sh Patching file ../ld/emulparams/elf64_ia64_fbsd.sh using Plan A... Hunk #1 succeeded at 4 with fuzz 2. patch: misordered hunks! output would be garbled % many thanks for your help anton -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Process accounting/timing has broken recently
On Sunday, December 05, 2010 6:18:29 pm Steve Kargl wrote: Sometime in the last 7-10 days, some one made a change that has broken process accounting/timing. laptop:kargl[42] foreach i ( 0 1 2 3 4 5 6 7 8 9 ) foreach? time ./testf foreach? end Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 69.55 real38.39 user30.94 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 68.82 real40.95 user27.60 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 69.14 real38.90 user30.02 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 68.79 real40.59 user27.99 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 68.93 real39.76 user28.96 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 68.71 real41.21 user27.29 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 69.05 real39.68 user29.15 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 68.99 real39.98 user28.80 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 69.02 real39.64 user29.16 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 69.38 real37.49 user31.67 sys testf is a numerically intensive program that tests the accuracy of expf() in a tight loop. User time varies by ~3 seconds on my lightly loaded 2 GHz core2 duo processor. I'm fairly certain that the code does not suddenly grow/loose 6 GFLOP of operations. The user/sys thing is a hack (and has been). We sample the PC at stathz (~128 hz) to figure out a user vs sys split and use that to divide up the total runtime (which actually is fairly accurate). All you need is for the clock ticks to fire just a bit differently between runs to get a swing in user vs system time. What I would like is to keep separate raw bintime's for user vs system time in the raw data instead, but that would involve checking the CPU ticker more often (e.g. twice for each syscall, interrupt, and trap in addition to the current once per context switch). So far folks seem to be more worried about the extra overhead rather than the loss of accuracy. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Process accounting/timing has broken recently
On Mon, Dec 06, 2010 at 09:44:03AM -0500, John Baldwin wrote: On Sunday, December 05, 2010 6:18:29 pm Steve Kargl wrote: Sometime in the last 7-10 days, some one made a change that has broken process accounting/timing. laptop:kargl[42] foreach i ( 0 1 2 3 4 5 6 7 8 9 ) foreach? time ./testf foreach? end Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 69.55 real38.39 user30.94 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 68.82 real40.95 user27.60 sys testf is a numerically intensive program that tests the accuracy of expf() in a tight loop. User time varies by ~3 seconds on my lightly loaded 2 GHz core2 duo processor. I'm fairly certain that the code does not suddenly grow/loose 6 GFLOP of operations. The user/sys thing is a hack (and has been). We sample the PC at stathz (~128 hz) to figure out a user vs sys split and use that to divide up the total runtime (which actually is fairly accurate). All you need is for the clock ticks to fire just a bit differently between runs to get a swing in user vs system time. What I would like is to keep separate raw bintime's for user vs system time in the raw data instead, but that would involve checking the CPU ticker more often (e.g. twice for each syscall, interrupt, and trap in addition to the current once per context switch). So far folks seem to be more worried about the extra overhead rather than the loss of accuracy. John, Thanks for the comment. It seems this splitting has become worse (for some definition of worse) in that previously the user time variation was on the order of tenth of a second not seconds. In thinking about the issue, I recalled that some changes to npx.c were committed 10 days ago. Perhaps, there is slightly more context switch overhead in dealing with the FPU registers, and this has increased the sys time. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
trying to use xz on manuals.
Hi.
I tested like following:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
--- share/mk/bsd.own.mk.orig2010-10-06 12:22:05.747697000 +0900
+++ share/mk/bsd.own.mk 2010-12-06 23:40:59.058632584 +0900
@@ -169,8 +169,8 @@
STRIP?=-s
.endif
-COMPRESS_CMD?= gzip -cn
-COMPRESS_EXT?= .gz
+COMPRESS_CMD?= xz -c
+COMPRESS_EXT?= .xz
.if !defined(_WITHOUT_SRCCONF)
#
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
So I got following results:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
$ find /usr/share/doc /usr/share/info /usr/share/man /usr/share/openssl/man
-name \*.gz | xargs stat -f %z | awk '{sum+=$0} END {print sum, NR}'
31186768 8629
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
$ find /usr/share/doc /usr/share/info /usr/share/man /usr/share/openssl/man
-name \*.xz | xargs stat -f %z | awk '{sum+=$0} END {print sum, NR}'
30010640 8631
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
.xz smaller than .gz, but effective is about 96.2%:-(.
Different from files.gz to files.xz:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
+/usr/share/man/man3/log2.3.xz
+/usr/share/man/man3/log2f.3.xz
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
(Sorry, .gz environment is just older)
And I noticed that tooo long ObsoleteFiles.inc:-(.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
# MMDD: Remove *.gz (Replaced by *.xz)
OLD_FILES+=usr/share/doc/papers/beyond43.ascii.gz
OLD_FILES+=usr/share/doc/papers/bio.ascii.gz
OLD_FILES+=usr/share/doc/papers/contents.ascii.gz
:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- -
Humm.. JFYI.
--
Norikatsu Shigemura n...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Process accounting/timing has broken recently
On Mon, Dec 06, 2010 at 08:38:30AM -0800, Steve Kargl wrote: On Mon, Dec 06, 2010 at 09:44:03AM -0500, John Baldwin wrote: On Sunday, December 05, 2010 6:18:29 pm Steve Kargl wrote: Sometime in the last 7-10 days, some one made a change that has broken process accounting/timing. laptop:kargl[42] foreach i ( 0 1 2 3 4 5 6 7 8 9 ) foreach? time ./testf foreach? end Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 69.55 real38.39 user30.94 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 68.82 real40.95 user27.60 sys testf is a numerically intensive program that tests the accuracy of expf() in a tight loop. User time varies by ~3 seconds on my lightly loaded 2 GHz core2 duo processor. I'm fairly certain that the code does not suddenly grow/loose 6 GFLOP of operations. The user/sys thing is a hack (and has been). We sample the PC at stathz (~128 hz) to figure out a user vs sys split and use that to divide up the total runtime (which actually is fairly accurate). All you need is for the clock ticks to fire just a bit differently between runs to get a swing in user vs system time. What I would like is to keep separate raw bintime's for user vs system time in the raw data instead, but that would involve checking the CPU ticker more often (e.g. twice for each syscall, interrupt, and trap in addition to the current once per context switch). So far folks seem to be more worried about the extra overhead rather than the loss of accuracy. John, Thanks for the comment. It seems this splitting has become worse (for some definition of worse) in that previously the user time variation was on the order of tenth of a second not seconds. In thinking about the issue, I recalled that some changes to npx.c were committed 10 days ago. Perhaps, there is slightly more context switch overhead in dealing with the FPU registers, and this has increased the sys time. If you can confirm this statement, it would be interesting. Otherwise, I claim that the changes did not affected the context switch path at all. The changes were mostly relevant for context(2) family of functions and debugger access to the FPU register file. pgp22NKWrueGR.pgp Description: PGP signature
Re: non-invariant tsc and cputicker
On Saturday 04 December 2010 06:12 am, Andriy Gapon wrote: on 04/12/2010 02:38 Jung-uk Kim said the following: If my understanding is correct, your patch uses the dummy timecounter until a real timecounter is chosen. Perhaps this is one way to look at it. But I look at it differently - the patch makes cpu_ticks refer to tc_cpu_ticks. That is, it make _the_ timecounter be used for cpu ticks. Exact timecounter backend is not important to me. When a real timecounter is set, tc_cpu_ticks() changes the frequency naturally. How are you going to solve this problem? Do we really care about cpu ticks accounting that early in the boot? What should we do when a user set a new timecounter hardware via sysctl kern.timecounter.hardware? User can expect some instability (*if any*) when he does such a significant system reconfiguration. I put if any, because I think that tc_cpu_ticks() should handle this. The same way as you don't see time returned by e.g. nanotime() going crazy at that moment. I don't think it is any better than current code. Am I missing something? :-( I think that it is much better. Handling of P-state changes for non-invariant TSC is just incorrect. kern.timecounter.hardware is not going to be changed as frequently as P-states, if ever. Sigh... Please see the history of calcru() in sys/kern/kern_resource.c. Most important ones are: http://svn.freebsd.org/viewvc/base?view=revisionrevision=155444 http://svn.freebsd.org/viewvc/base?view=revisionrevision=155534 Basically, we chose efficiency over accuracy and you are suggesting going backwards. Jung-uk Kim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: trying to use xz on manuals.
On Tue, Dec 07, 2010 at 02:03:50AM +0900, Norikatsu Shigemura wrote: .xz smaller than .gz, but effective is about 96.2%:-(. Some time ago I do similar tests. Changing compression for base man's to bz2 or xz doesn't make much sense. -- Adios RELENG_8 2010-04-26: 4,0M/tmp/mangzxz.hm0P7PH4xi/1_raw 1,7M/tmp/mangzxz.hm0P7PH4xi/1gz 1,6M/tmp/mangzxz.hm0P7PH4xi/1xz 1,1M/tmp/mangzxz.hm0P7PH4xi/2_raw 604K/tmp/mangzxz.hm0P7PH4xi/2gz 598K/tmp/mangzxz.hm0P7PH4xi/2xz 5,7M/tmp/mangzxz.hm0P7PH4xi/3_raw 2,6M/tmp/mangzxz.hm0P7PH4xi/3gz 2,6M/tmp/mangzxz.hm0P7PH4xi/3xz 3,5M/tmp/mangzxz.hm0P7PH4xi/4_raw 1,7M/tmp/mangzxz.hm0P7PH4xi/4gz 1,7M/tmp/mangzxz.hm0P7PH4xi/4xz 1,8M/tmp/mangzxz.hm0P7PH4xi/5_raw 748K/tmp/mangzxz.hm0P7PH4xi/5gz 718K/tmp/mangzxz.hm0P7PH4xi/5xz 10K/tmp/mangzxz.hm0P7PH4xi/6_raw 6,0K/tmp/mangzxz.hm0P7PH4xi/6gz 6,0K/tmp/mangzxz.hm0P7PH4xi/6xz 804K/tmp/mangzxz.hm0P7PH4xi/7_raw 308K/tmp/mangzxz.hm0P7PH4xi/7gz 296K/tmp/mangzxz.hm0P7PH4xi/7xz 3,0M/tmp/mangzxz.hm0P7PH4xi/8_raw 1,4M/tmp/mangzxz.hm0P7PH4xi/8gz 1,4M/tmp/mangzxz.hm0P7PH4xi/8xz 2,1M/tmp/mangzxz.hm0P7PH4xi/9_raw 1,0M/tmp/mangzxz.hm0P7PH4xi/9gz 1,0M/tmp/mangzxz.hm0P7PH4xi/9xz ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: non-invariant tsc and cputicker
on 06/12/2010 19:42 Jung-uk Kim said the following: Sigh... Please see the history of calcru() in sys/kern/kern_resource.c. Most important ones are: http://svn.freebsd.org/viewvc/base?view=revisionrevision=155444 http://svn.freebsd.org/viewvc/base?view=revisionrevision=155534 Basically, we chose efficiency over accuracy and you are suggesting going backwards. Well, I guess that it depends. Looking at r155444 - the time is still going to be accounted in ticks (but timecounter ticks). BTW, I think that this quote says something: On more modern hardware no change in performance is seen. and that was ~5 years ago. Looking at r155534 - the only change that is going to get undone is using TSC for the accounting ticks, and that is only for machines with non-invariant TSC. And I think that all sufficiently modern machines have invariant TSC and, in Intel's words, that's an architectural path going forward. So, I don't think that I propose a dramatic change. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Process accounting/timing has broken recently
On Monday, December 06, 2010 11:38:30 am Steve Kargl wrote: On Mon, Dec 06, 2010 at 09:44:03AM -0500, John Baldwin wrote: On Sunday, December 05, 2010 6:18:29 pm Steve Kargl wrote: Sometime in the last 7-10 days, some one made a change that has broken process accounting/timing. laptop:kargl[42] foreach i ( 0 1 2 3 4 5 6 7 8 9 ) foreach? time ./testf foreach? end Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 69.55 real38.39 user30.94 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 68.82 real40.95 user27.60 sys testf is a numerically intensive program that tests the accuracy of expf() in a tight loop. User time varies by ~3 seconds on my lightly loaded 2 GHz core2 duo processor. I'm fairly certain that the code does not suddenly grow/loose 6 GFLOP of operations. The user/sys thing is a hack (and has been). We sample the PC at stathz (~128 hz) to figure out a user vs sys split and use that to divide up the total runtime (which actually is fairly accurate). All you need is for the clock ticks to fire just a bit differently between runs to get a swing in user vs system time. What I would like is to keep separate raw bintime's for user vs system time in the raw data instead, but that would involve checking the CPU ticker more often (e.g. twice for each syscall, interrupt, and trap in addition to the current once per context switch). So far folks seem to be more worried about the extra overhead rather than the loss of accuracy. John, Thanks for the comment. It seems this splitting has become worse (for some definition of worse) in that previously the user time variation was on the order of tenth of a second not seconds. In thinking about the issue, I recalled that some changes to npx.c were committed 10 days ago. Perhaps, there is slightly more context switch overhead in dealing with the FPU registers, and this has increased the sys time. Hmm, I wonder if the eventtimer stuff that has gone into HEAD recently could be a factor? It might change when statclock() is called. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Process accounting/timing has broken recently
On Mon, Dec 06, 2010 at 07:35:31PM +0200, Kostik Belousov wrote: On Mon, Dec 06, 2010 at 08:38:30AM -0800, Steve Kargl wrote: John, Thanks for the comment. It seems this splitting has become worse (for some definition of worse) in that previously the user time variation was on the order of tenth of a second not seconds. In thinking about the issue, I recalled that some changes to npx.c were committed 10 days ago. Perhaps, there is slightly more context switch overhead in dealing with the FPU registers, and this has increased the sys time. If you can confirm this statement, it would be interesting. Otherwise, I claim that the changes did not affected the context switch path at all. The changes were mostly relevant for context(2) family of functions and debugger access to the FPU register file. I won't be able to test this possibiolity until later tonight (about 9 hours from now). -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Process accounting/timing has broken recently
on 06/12/2010 20:01 John Baldwin said the following: Hmm, I wonder if the eventtimer stuff that has gone into HEAD recently could be a factor? It might change when statclock() is called. But I think that that code was committed more than 7-10 days ago, which Steve mentioned. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: non-invariant tsc and cputicker
On Monday 06 December 2010 12:58 pm, Andriy Gapon wrote: on 06/12/2010 19:42 Jung-uk Kim said the following: Sigh... Please see the history of calcru() in sys/kern/kern_resource.c. Most important ones are: http://svn.freebsd.org/viewvc/base?view=revisionrevision=155444 http://svn.freebsd.org/viewvc/base?view=revisionrevision=155534 Basically, we chose efficiency over accuracy and you are suggesting going backwards. Well, I guess that it depends. Looking at r155444 - the time is still going to be accounted in ticks (but timecounter ticks). BTW, I think that this quote says something: On more modern hardware no change in performance is seen. and that was ~5 years ago. On slower machines, the avoided multiplications to normalize timestams at every context switch, comes out as a 5-7% better score on the unixbench/context1 microbenchmark. On more modern hardware no change in performance is seen. His performance measurement was done for the avoided multiplications to normalize timestamps at every context switch, not for change CPU ticker from tc_cpu_ticks() to cpu_ticks(), which actually happened in r155534 later. Looking at r155534 - the only change that is going to get undone is using TSC for the accounting ticks, and that is only for machines with non-invariant TSC. And I think that all sufficiently modern machines have invariant TSC and, in Intel's words, that's an architectural path going forward. I understand that. However, it is not clear to me why you want to pessimize performance of old hardware. If you can convince me old hardware with slow timecounter hardware (e.g., i8254) does not hurt too much, maybe it's okay. So, I don't think that I propose a dramatic change. Shrug... Still I want to see some evidence. Jung-uk Kim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: non-invariant tsc and cputicker
on 06/12/2010 20:34 Jung-uk Kim said the following: On Monday 06 December 2010 12:58 pm, Andriy Gapon wrote: on 06/12/2010 19:42 Jung-uk Kim said the following: Sigh... Please see the history of calcru() in sys/kern/kern_resource.c. Most important ones are: http://svn.freebsd.org/viewvc/base?view=revisionrevision=155444 http://svn.freebsd.org/viewvc/base?view=revisionrevision=155534 Basically, we chose efficiency over accuracy and you are suggesting going backwards. Well, I guess that it depends. Looking at r155444 - the time is still going to be accounted in ticks (but timecounter ticks). BTW, I think that this quote says something: On more modern hardware no change in performance is seen. and that was ~5 years ago. On slower machines, the avoided multiplications to normalize timestams at every context switch, comes out as a 5-7% better score on the unixbench/context1 microbenchmark. On more modern hardware no change in performance is seen. His performance measurement was done for the avoided multiplications to normalize timestamps at every context switch, not for change CPU ticker from tc_cpu_ticks() to cpu_ticks(), which actually happened in r155534 later. Right. I was just pointing out a fact. That change is not going to get undone anyways. Looking at r155534 - the only change that is going to get undone is using TSC for the accounting ticks, and that is only for machines with non-invariant TSC. And I think that all sufficiently modern machines have invariant TSC and, in Intel's words, that's an architectural path going forward. I understand that. However, it is not clear to me why you want to pessimize performance of old hardware. If you can convince me old hardware with slow timecounter hardware (e.g., i8254) does not hurt too much, maybe it's okay. Well, weighing totally bogus stats vs slight stats collection pessimization, I have a new proposal - why we don't just hardcode some stats values? That would give that code unbeatable performance! So, I don't think that I propose a dramatic change. Shrug... Still I want to see some evidence. Evidence of what? That nothing is going to be changed for new hardware? Or that older hardware won't be slowed down to a crawl? -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Process accounting/timing has broken recently
On Mon, Dec 06, 2010 at 08:24:27PM +0200, Andriy Gapon wrote: on 06/12/2010 20:01 John Baldwin said the following: Hmm, I wonder if the eventtimer stuff that has gone into HEAD recently could be a factor? It might change when statclock() is called. But I think that that code was committed more than 7-10 days ago, which Steve mentioned. The 7-10 days is an estimate. I upgraded world/kernel on Saturday. The previous world/kernel could have been older than I'm guessing. It could be upto 4 weeks old because my laptop tends to lag behind the upgrades to my servers. I would normally use gprof to measure execution times for the functions I'm writing, but in some quick testing last night gprof appears to be broken. I'm seeing a larger variation that I would expect in self-seconds for the accumulated time for execution of expf. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Process accounting/timing has broken recently
on 06/12/2010 20:43 Steve Kargl said the following: The 7-10 days is an estimate. I upgraded world/kernel on Saturday. The previous world/kernel could have been older than I'm guessing. It could be upto 4 weeks old because my laptop tends to lag behind the upgrades to my servers. I see. I would normally use gprof to measure execution times for the functions I'm writing, but in some quick testing last night gprof appears to be broken. I'm seeing a larger variation that I would expect in self-seconds for the accumulated time for execution of expf. Just guessing - could you try setting sysctl kern.eventtimer.periodic=1 if it's not 1 already? And cc-ing Alexander, just in case. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Process accounting/timing has broken recently
On Mon, Dec 06, 2010 at 08:46:15PM +0200, Andriy Gapon wrote: on 06/12/2010 20:43 Steve Kargl said the following: The 7-10 days is an estimate. I upgraded world/kernel on Saturday. The previous world/kernel could have been older than I'm guessing. It could be upto 4 weeks old because my laptop tends to lag behind the upgrades to my servers. I see. I would normally use gprof to measure execution times for the functions I'm writing, but in some quick testing last night gprof appears to be broken. I'm seeing a larger variation that I would expect in self-seconds for the accumulated time for execution of expf. Just guessing - could you try setting sysctl kern.eventtimer.periodic=1 if it's not 1 already? And cc-ing Alexander, just in case. Thanks for the suggestion. I'll try this tonight (I left the laptop at home) and will report back here. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: coretemp TjMax
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hi,
On 12/04/10 13:59, Irakli wrote:
Hi,
ns# cpucontrol -m 0x1a2 /dev/cpuctl0
MSR 0x1a2: 0x 0x1600
ns# grep GenuineIntel /var/run/dmesg.boot
Origin = GenuineIntel Id = 0x6fb Family = 6 Model = f Stepping = 11
I didn't found any authoritative source that gives me 95. Where did you
get the information?
Attached is a patch that uses 95C for stepping G0 but I'm really
clueless whether that's right.
On Tue, Nov 23, 2010 at 5:13 PM, Xin LI delp...@delphij.net
mailto:delp...@delphij.net wrote:
[Redirected to -curr...@]
Hi,
On 11/15/10 03:32, Irakli wrote:
Hi
coretemp gets wrong TjMax for Intel E6750 CPU (CPUID 06FBh), 85
instead of
95.
and therefore monitoring programs see low then room temperature
(in air
cooling)
Please fix this and would be nice allowing users manual setting
TjMax from
sysctl
Would you please provide the following information?
cpucontrol -m 0x1a2 /dev/cpuctl0
(kldload cpuctl if necessary).
And:
grep GenuineIntel /var/run/dmesg.boot
Thanks in advance!
Cheers,
- --
Xin LI delp...@delphij.nethttp://www.delphij.net/
FreeBSD - The Power to Serve! Live free or die
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (FreeBSD)
iQEcBAEBCAAGBQJM/TCpAAoJEATO+BI/yjfBoxwH/RzrcuHXjo8buG3suGheD2kP
4N1LNMR/lPzmlG9duhqPOE3Y7DsKqe/tiZ91QykyFmJylePHf5gAv+bASP8An+xv
piyq12ghePUoWsl9kYJwSBQ1wkvpkYf6RJ+mWIGTMp3+xpmEa9yyQnnE2AvSWAga
HduALNzJnqqxQwlHFFqi216ay79ItUPvJEWCGeP1AfGt3CJqg1aAJ8fY3rF7m37P
whWg89QqWu6U0WDJ2QFmzJxxtbyHIT9CUcGsJrpfZKVQf2kglPn0rPSLjaBTQcGK
RJMyOW3KI/LueSJ+PgvRNtaSVhhGL2cm4L9Mz2uo/vp5OVoe48oWn68dZgFkffw=
=MKgf
-END PGP SIGNATURE-
Index: coretemp.c
===
--- coretemp.c (revision 216236)
+++ coretemp.c (working copy)
@@ -178,8 +178,13 @@
*/
sc-sc_tjmax = 100;
- if ((cpu_model == 0xf cpu_stepping = 2) || cpu_model == 0xe) {
+ if (cpu_model == 0xf cpu_stepping == 11) {
/*
+* Use 95C for stepping G0
+*/
+ sc-sc_tjmax = 95;
+ } else if ((cpu_model == 0xf cpu_stepping = 2) || cpu_model == 0xe)
{
+ /*
* On some Core 2 CPUs, there's an undocumented MSR that
* can tell us if Tj(max) is 100 or 85.
*
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: non-invariant tsc and cputicker
on 06/12/2010 20:34 Jung-uk Kim said the following: I understand that. However, it is not clear to me why you want to pessimize performance of old hardware. If you can convince me old hardware with slow timecounter hardware (e.g., i8254) does not hurt too much, maybe it's okay. Overlooked this point - TSC can be very well used as a timecounter. And in that case non-invariant TSC would veto P-state changes, which is the proper thing to do, IMO. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Process accounting/timing has broken recently
On 06.12.2010 20:49, Steve Kargl wrote: On Mon, Dec 06, 2010 at 08:46:15PM +0200, Andriy Gapon wrote: on 06/12/2010 20:43 Steve Kargl said the following: The 7-10 days is an estimate. I upgraded world/kernel on Saturday. The previous world/kernel could have been older than I'm guessing. It could be upto 4 weeks old because my laptop tends to lag behind the upgrades to my servers. I see. I would normally use gprof to measure execution times for the functions I'm writing, but in some quick testing last night gprof appears to be broken. I'm seeing a larger variation that I would expect in self-seconds for the accumulated time for execution of expf. Just guessing - could you try setting sysctl kern.eventtimer.periodic=1 if it's not 1 already? And cc-ing Alexander, just in case. Thanks for the suggestion. I'll try this tonight (I left the laptop at home) and will report back here. Unless your application utilizes all CPUs all the time, you can also try to set sysctl kern.eventtimer.idletick=1. -- Alexander Motin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: non-invariant tsc and cputicker
On Monday 06 December 2010 01:40 pm, Andriy Gapon wrote: on 06/12/2010 20:34 Jung-uk Kim said the following: On Monday 06 December 2010 12:58 pm, Andriy Gapon wrote: on 06/12/2010 19:42 Jung-uk Kim said the following: Sigh... Please see the history of calcru() in sys/kern/kern_resource.c. Most important ones are: http://svn.freebsd.org/viewvc/base?view=revisionrevision=15544 4 http://svn.freebsd.org/viewvc/base?view=revisionrevision=15553 4 Basically, we chose efficiency over accuracy and you are suggesting going backwards. Well, I guess that it depends. Looking at r155444 - the time is still going to be accounted in ticks (but timecounter ticks). BTW, I think that this quote says something: On more modern hardware no change in performance is seen. and that was ~5 years ago. On slower machines, the avoided multiplications to normalize timestams at every context switch, comes out as a 5-7% better score on the unixbench/context1 microbenchmark. On more modern hardware no change in performance is seen. His performance measurement was done for the avoided multiplications to normalize timestamps at every context switch, not for change CPU ticker from tc_cpu_ticks() to cpu_ticks(), which actually happened in r155534 later. Right. I was just pointing out a fact. That change is not going to get undone anyways. Looking at r155534 - the only change that is going to get undone is using TSC for the accounting ticks, and that is only for machines with non-invariant TSC. And I think that all sufficiently modern machines have invariant TSC and, in Intel's words, that's an architectural path going forward. I understand that. However, it is not clear to me why you want to pessimize performance of old hardware. If you can convince me old hardware with slow timecounter hardware (e.g., i8254) does not hurt too much, maybe it's okay. Well, weighing totally bogus stats vs slight stats collection pessimization, I have a new proposal - why we don't just hardcode some stats values? That would give that code unbeatable performance! :-) Don't get me wrong, I generally agree with you *iff* it does not hurt too much. Anyway, this issue should be resolved from the root, i.e., kern_resouce.c, if possible. So, I don't think that I propose a dramatic change. Shrug... Still I want to see some evidence. Evidence of what? That nothing is going to be changed for new hardware? Or that older hardware won't be slowed down to a crawl? The latter, kinda. Jung-uk Kim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: non-invariant tsc and cputicker
on 06/12/2010 21:01 Jung-uk Kim said the following: :-) Don't get me wrong, I generally agree with you *iff* it does not hurt too much. Anyway, this issue should be resolved from the root, i.e., kern_resouce.c, if possible. But what to resolve there? I just want to always have a stable source cpu ticks, and then everything else should just work? BTW, if someone comes up with a patch for more or less correct accounting when cpu ticks frequency is allowed to change, then I am all for it. But, IMO, it's just easier to use stable cpu ticks. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: non-invariant tsc and cputicker
On Monday 06 December 2010 01:56 pm, Andriy Gapon wrote: on 06/12/2010 20:34 Jung-uk Kim said the following: I understand that. However, it is not clear to me why you want to pessimize performance of old hardware. If you can convince me old hardware with slow timecounter hardware (e.g., i8254) does not hurt too much, maybe it's okay. Overlooked this point - TSC can be very well used as a timecounter. And in that case non-invariant TSC would veto P-state changes, which is the proper thing to do, IMO. Yes, thanks to njl. He made it somewhat bogus from totally bogus. I made it almost correct from somewhat bogus for modern P-state invariant CPUs. ;-) Jung-uk Kim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: trying to use xz on manuals.
On Dec 6, 2010, at 9:13 AM, Alex Kozlov wrote: On Tue, Dec 07, 2010 at 02:03:50AM +0900, Norikatsu Shigemura wrote: .xz smaller than .gz, but effective is about 96.2%:-(. Some time ago I do similar tests. Changing compression for base man's to bz2 or xz doesn't make much sense. Oh, agreed. The issue with small files is that they will always take up at least one sector [*]; different compression routines don't gain any benefit if they don't change the number of sectors needed to store the file. More than half of the manpages end up as 1K .gz catman files as it is; ~90% are 2K or smaller. Regards, -- -Chuck [*]: 1K seems to be the smallest fragment size on the particular filesystem I was looking at, rather than DEV_BSIZE, ie a 512 byte sector ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: non-invariant tsc and cputicker
On Monday 06 December 2010 02:09 pm, Andriy Gapon wrote: on 06/12/2010 21:01 Jung-uk Kim said the following: :-) Don't get me wrong, I generally agree with you *iff* it does : not hurt too much. Anyway, this issue should be resolved from the root, i.e., kern_resouce.c, if possible. But what to resolve there? Better algorithm for stat. I just want to always have a stable source cpu ticks, and then everything else should just work? If we had one, yes. But we don't, at least for old x86 hardware. :-( BTW, if someone comes up with a patch for more or less correct accounting when cpu ticks frequency is allowed to change, then I am all for it. But, IMO, it's just easier to use stable cpu ticks. If it doesn't hurt too much, yes. Remember the P-state invariant CPUs are pretty new. SMP-correct TSC is quite rare if there is any. Jung-uk Kim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: non-invariant tsc and cputicker
on 06/12/2010 21:27 Jung-uk Kim said the following: On Monday 06 December 2010 02:09 pm, Andriy Gapon wrote: on 06/12/2010 21:01 Jung-uk Kim said the following: :-) Don't get me wrong, I generally agree with you *iff* it does : not hurt too much. Anyway, this issue should be resolved from the root, i.e., kern_resouce.c, if possible. But what to resolve there? Better algorithm for stat. I just want to always have a stable source cpu ticks, and then everything else should just work? If we had one, yes. But we don't, at least for old x86 hardware. :-( This sounds contradictory... I don't follow. So, TSC as a direct source of cpu ticks is good enough, but TSC as a source for timecounter acting as a source for cpu ticks is not stable? BTW, if someone comes up with a patch for more or less correct accounting when cpu ticks frequency is allowed to change, then I am all for it. But, IMO, it's just easier to use stable cpu ticks. If it doesn't hurt too much, yes. Remember the P-state invariant CPUs are pretty new. Well, not that new in this fast changing world. SMP-correct TSC is quite rare if there is any. This contradicts my experience. All systems that I could test have SMP-correct TSC. Yes, they all are 1-2 years old and they all are single-package multi-core systems. I tested only one two-socket machine from perf-cluster and it had more or less SMP-correct TSC too. BTW: http://people.freebsd.org/~avg/tsc/ But, this SMP-correctness is not a requirement for the cpu ticks accounting that we are discussing, right? -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: non-invariant tsc and cputicker
On Monday 06 December 2010 02:38 pm, Andriy Gapon wrote: on 06/12/2010 21:27 Jung-uk Kim said the following: On Monday 06 December 2010 02:09 pm, Andriy Gapon wrote: on 06/12/2010 21:01 Jung-uk Kim said the following: :-) Don't get me wrong, I generally agree with you *iff* it : does not hurt too much. Anyway, this issue should be resolved from the root, i.e., kern_resouce.c, if possible. But what to resolve there? Better algorithm for stat. I just want to always have a stable source cpu ticks, and then everything else should just work? If we had one, yes. But we don't, at least for old x86 hardware. :-( This sounds contradictory... I don't follow. So, TSC as a direct source of cpu ticks is good enough, but TSC as a source for timecounter acting as a source for cpu ticks is not stable? CPU ticker is per-CPU property, not global. So, it is okay even if it cannot be used as a timecounter backend. If TSC is selected as a timecounter source, that means a) it is a P-state invariant UP system or b) the user forced it. If the CPU is P-state invariant, it does not matter it is UP or SMP because it is per-CPU property. If the CPU is not invariant or UP system, then it does not allow frequency changes as you've noticed. If the user forced it on SMP, well, the user should know its consequence. ;-) BTW, if someone comes up with a patch for more or less correct accounting when cpu ticks frequency is allowed to change, then I am all for it. But, IMO, it's just easier to use stable cpu ticks. If it doesn't hurt too much, yes. Remember the P-state invariant CPUs are pretty new. Well, not that new in this fast changing world. But most of our users do have old hardware, unfortunately. SMP-correct TSC is quite rare if there is any. This contradicts my experience. All systems that I could test have SMP-correct TSC. Yes, they all are 1-2 years old and they all are single-package multi-core systems. AFAIK, multi-core/single-package/single-socket systems have usually P-state invariant TSCs already, i.e., it can be used as a CPU ticker naturally. I tested only one two-socket machine from perf-cluster and it had more or less SMP-correct TSC too. Unfortunately more or less does not work for us because timecounter should never go backwards. It MUST be monotonic. BTW: http://people.freebsd.org/~avg/tsc/ Interesting... I've seen something like this in the past. In fact, I've written my own long ago but I wasn't able to make it 100% correct, unfortunately. :-( But, this SMP-correctness is not a requirement for the cpu ticks accounting that we are discussing, right? No, it is not. Sorry, if I confused you somehow. Jung-uk Kim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Process accounting/timing has broken recently
John Baldwin wrote: On Sunday, December 05, 2010 6:18:29 pm Steve Kargl wrote: Sometime in the last 7-10 days, some one made a change that has broken process accounting/timing. laptop:kargl[42] foreach i ( 0 1 2 3 4 5 6 7 8 9 ) foreach? time ./testf foreach? end Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 69.55 real38.39 user30.94 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 68.82 real40.95 user27.60 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 69.14 real38.90 user30.02 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 68.79 real40.59 user27.99 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 68.93 real39.76 user28.96 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 68.71 real41.21 user27.29 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 69.05 real39.68 user29.15 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 68.99 real39.98 user28.80 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 69.02 real39.64 user29.16 sys Max ULP: 0.501607 for x in [-18.00:88.70] with dx = 1.067100e-04 69.38 real37.49 user31.67 sys testf is a numerically intensive program that tests the accuracy of expf() in a tight loop. User time varies by ~3 seconds on my lightly loaded 2 GHz core2 duo processor. I'm fairly certain that the code does not suddenly grow/loose 6 GFLOP of operations. The user/sys thing is a hack (and has been). We sample the PC at stathz (~128 hz) to figure out a user vs sys split and use that to divide up the total runtime (which actually is fairly accurate). All you need is for the clock ticks to fire just a bit differently between runs to get a swing in user vs system time. What I would like is to keep separate raw bintime's for user vs system time in the raw data instead, but that would involve checking the CPU ticker more often (e.g. twice for each syscall, interrupt, and trap in addition to the current once per context switch). So far folks seem to be more worried about the extra overhead rather than the loss of accuracy. Adding any instruction into global syscall path should be cautioned, it is worse then before, thinking about a threaded application, a userland thread may have locked a mutex and calls a system call, the overhead added to system call path can directly affect a threaded application's performance now, because the time window the mutex is held is longer than before, I have seen some people likes to fiddle with system call path, it should be cautioned. Regards, David Xu ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: coretemp TjMax
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, On 12/06/10 12:52, Irakli wrote: Information about this cpu I get from windows coretemp program http://www.alcpu.com/CoreTemp/ this is screenshot of this program (new version) http://technbball.files.wordpress.com/2009/09/coretemp_e6750.jpg older version gets 100 degree for this cpu http://img233.imageshack.us/img233/8525/voltagecm9.jpg and some forums http://www.overclock.net/intel-cpus/378478-tjmax-e6750.html I haven't any authoritative source but sure 85 degree is wrong for this cpu because freebsd gets lower core temperature then room temperature is Ok to make it clear - I did see some forums mentioned 95 C but these are not authoritative in my opinion (e.g. I was not able to figure out if all 0x6fb CPUs have 95C TjMax, or just a few models, etc). can you add some code for setting tjmax manualy from sysctl ? Yes will do. Did the patch help your situation by the way? thank you On Mon, Dec 6, 2010 at 10:51 PM, Xin LI delp...@delphij.net mailto:delp...@delphij.net wrote: Hi, On 12/04/10 13:59, Irakli wrote: Hi, ns# cpucontrol -m 0x1a2 /dev/cpuctl0 MSR 0x1a2: 0x 0x1600 ns# grep GenuineIntel /var/run/dmesg.boot Origin = GenuineIntel Id = 0x6fb Family = 6 Model = f Stepping = 11 I didn't found any authoritative source that gives me 95. Where did you get the information? Attached is a patch that uses 95C for stepping G0 but I'm really clueless whether that's right. On Tue, Nov 23, 2010 at 5:13 PM, Xin LI delp...@delphij.net mailto:delp...@delphij.net mailto:delp...@delphij.net mailto:delp...@delphij.net wrote: [Redirected to -curr...@] Hi, On 11/15/10 03:32, Irakli wrote: Hi coretemp gets wrong TjMax for Intel E6750 CPU (CPUID 06FBh), 85 instead of 95. and therefore monitoring programs see low then room temperature (in air cooling) Please fix this and would be nice allowing users manual setting TjMax from sysctl Would you please provide the following information? cpucontrol -m 0x1a2 /dev/cpuctl0 (kldload cpuctl if necessary). And: grep GenuineIntel /var/run/dmesg.boot Thanks in advance! Cheers, -- ][rakli - -- Xin LI delp...@delphij.nethttp://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (FreeBSD) iQEcBAEBCAAGBQJM/Y6hAAoJEATO+BI/yjfB6tAIAJSzuNDQEKBhwaXHGKBTavai 2OlF8L+clazY2BrhzV0sBWnqewABHMHmEwtWqM+dp7GkD0TuiD9Shft4NG/pC+Hm wT/7aF7Ipa0jrH6bo5oqk42oqNWOKt6edBSARdYtodtRTRKAFocyje0J0XNpw6r8 AWXxM1NXNM0/+Nf0ZG1jwLu8WhLGQ9V0eJ510Kd1uKh+jZkyOnBlP3tipkrDLgRQ x8CdCJHtuWrqIk8KIOqqMMT3WVpddP4hdNH7usQYkHYh3bVthTamz75E+fGDut9w Poia7FnRXC5odC1EWU8QUMuzpSzNM5Hy/6ePKOrxhfr0x9WpyssJzl9tPHfp/2s= =cPJd -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: trying to use xz on manuals.
On Dec 6, 2010, at 11:17 AM, Chuck Swiger wrote: On Dec 6, 2010, at 9:13 AM, Alex Kozlov wrote: On Tue, Dec 07, 2010 at 02:03:50AM +0900, Norikatsu Shigemura wrote: .xz smaller than .gz, but effective is about 96.2%:-(. Some time ago I do similar tests. Changing compression for base man's to bz2 or xz doesn't make much sense. Oh, agreed. The issue with small files is that they will always take up at least one sector [*]; different compression routines don't gain any benefit if they don't change the number of sectors needed to store the file. More than half of the manpages end up as 1K .gz catman files as it is; ~90% are 2K or smaller. It might make sense if XZ decompression were significantly faster than GZip decompression. (Especially since man pages are decompressed much more often than they are compressed.) Tim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
