Date: Fri, 16 Dec 2016 16:30:48 -0700 From: Ian Lepore <ian@freebsd.org> To: Konstantin Belousov <kostikbel@gmail.com> Cc: freebsd-hackers@freebsd.org Subject: Re: How to use sem_timedwait? Message-ID: <1481931048.1343.2.camel@freebsd.org> In-Reply-To: <20161216184553.GC94325@kib.kiev.ua> References: <20161214074228.zh6q5zya2gszw4g6@hal9000.meka.no-ip.org> <1481748960.1889.398.camel@freebsd.org> <20161215002906.mllorgvvuovbdtze@hal9000.meka.no-ip.org> <1481775511.1889.450.camel@freebsd.org> <1481776532.1889.461.camel@freebsd.org> <20161215112050.GO94325@kib.kiev.ua> <1481817343.1889.467.camel@freebsd.org> <20161215171534.GV94325@kib.kiev.ua> <1481911613.1972.74.camel@freebsd.org> <20161216184553.GC94325@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 2016-12-16 at 20:45 +0200, Konstantin Belousov wrote:
> On Fri, Dec 16, 2016 at 11:06:53AM -0700, Ian Lepore wrote:
> >
> > I tried LAPIC, HPET, and i8254 for eventtimer.hardware, there was
> > no
> > change with any of them. I tried turning periodic on, still no
> > change.
> > Changing alloweddeviation made no change. I tried different
> > hardware
> > choices for timecounter too (not that timecounting is showing any
> > signs
> > of trouble on this machine), no change.
> >
> > revolution > sysctl dev.cpu.0
> > dev.cpu.0.cx_usage: 100.00% 0.00% 0.00% last 303us
> > dev.cpu.0.cx_lowest: C1
> > dev.cpu.0.cx_supported: C1/1/32 C2/2/96 C3/3/128
> > dev.cpu.0.freq_levels: 3334/143000 3333/130000 3200/117000
> > 3067/105000
> > 2933/94000 2800/85000 2667/76000 2533/68000 2400/61000 2267/54000
> > 2133/48000 2000/43000 1867/39000 1733/35000 1600/32000
> > dev.cpu.0.freq: 3333
> > dev.cpu.0.temperature: 69.0C
> > dev.cpu.0.coretemp.throttle_log: 0
> > dev.cpu.0.coretemp.tjmax: 101.0C
> > dev.cpu.0.coretemp.resolution: 1
> > dev.cpu.0.coretemp.delta: 32
> > dev.cpu.0.%parent: acpi0
> > dev.cpu.0.%pnpinfo: _HID=none _UID=0
> > dev.cpu.0.%location: handle=\_PR_.P001
> > dev.cpu.0.%driver: cpu
> > dev.cpu.0.%desc: ACPI CPU
> >
> > I also ran the test program on a couple servers at $work runing
> > 10.3-
> > stable, and they both showed identical behavior, with the result in
> > the
> > same range as on this machine: nsec = 9315538211 for 1000000 loops
> > of
> > 10000 nsec.
> >
> > One of those machines is running as a vmware guest:
> >
> > FreeBSD 10.3-STABLE-20161014 #2 r307350M: Mon Oct 17 18:07:23 MDT
> > 2016
> > FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032)
> > 20140512
> > CPU: Intel(R) Xeon(R) CPU E5-2650 v4 @ 2.20GHz (2197.45-MHz K8-
> > class CPU)
> >
> > Origin="GenuineIntel" Id=0x206d2 Family=0x6 Model=0x2d Stepping
> > =2
> >
> > Features=0xfa3fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR
> > ,PGE,MCA,CMOV,PAT,PSE36,DTS,MMX,FXSR,SSE,SSE2,SS>
> >
> > Features2=0x9fba2203<SSE3,PCLMULQDQ,SSSE3,CX16,PCID,SSE4.1,SSE4.2,x
> > 2APIC,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,HV>
> > AMD Features=0x28100800<SYSCALL,NX,RDTSCP,LM>
> > AMD Features2=0x1<LAHF>
> > Structured Extended Features=0x2<TSCADJ>
> > TSC: P-state invariant
> > Hypervisor: Origin = "VMwareVMware"
> > real memory = 2147483648 (2048 MB)
> > avail memory = 2050031616 (1955 MB)
> > Event timer "LAPIC" quality 600
> >
> > and the other is running on bare metal:
> >
> > FreeBSD 10.3-STABLE-20161014 #2 r307350M: Mon Oct 17 18:30:37 MDT
> > 2016
> > CPU: Intel(R) Xeon(R) CPU X5550 @ 2.67GHz (2660.05-MHz
> > K8-class CPU)
> >
> > Origin="GenuineIntel" Id=0x106a5 Family=0x6 Model=0x1a Stepping
> > =5
> >
> > Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTR
> > R,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,
> > TM,PBE>
> >
> > Features2=0x9ce3bd<SSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xT
> > PR,PDCM,DCA,SSE4.1,SSE4.2,POPCNT>
> > AMD Features=0x28100800<SYSCALL,NX,RDTSCP,LM>
> > AMD Features2=0x1<LAHF>
> > VT-x: PAT,HLT,MTF,PAUSE,EPT,VPID
> > TSC: P-state invariant, performance statistics
> > real memory = 206158430208 (196608 MB)
> > avail memory = 200380227584 (191097 MB)
> > Event timer "LAPIC" quality 400
> Am I right that you only tested on stable/10 machines ? What you see
> and I do not, might be due to the missed MFC of r296775, which commit
> message claims that it fixes truncation in converions.
>
> Below is the commit merged to stable/10, could you test it ? I do
> not
> have any stable/10 machine.
>
> Index: sys/kern/kern_event.c
> ===================================================================
> --- sys/kern/kern_event.c (revision 310169)
> +++ sys/kern/kern_event.c (working copy)
> @@ -556,34 +556,59 @@ knote_fork(struct knlist *list, int pid)
> #define NOTE_TIMER_PRECMASK (NOTE_SECONDS|NOTE_MSECONDS|NOTE_
> USECONDS| \
> NOTE_NSECONDS)
>
> -static __inline sbintime_t
> +static sbintime_t
> timer2sbintime(intptr_t data, int flags)
> {
> - sbintime_t modifier;
>
> + /*
> + * Macros for converting to the fractional second portion of
> an
> + * sbintime_t using 64bit multiplication to improve
> precision.
> + */
> +#define NS_TO_SBT(ns) (((ns) * (((uint64_t)1 << 63) / 500000000)) >>
> 32)
> +#define US_TO_SBT(us) (((us) * (((uint64_t)1 << 63) / 500000)) >>
> 32)
> +#define MS_TO_SBT(ms) (((ms) * (((uint64_t)1 << 63) / 500)) >> 32)
> switch (flags & NOTE_TIMER_PRECMASK) {
> case NOTE_SECONDS:
> - modifier = SBT_1S;
> - break;
> +#ifdef __LP64__
> + if (data > (SBT_MAX / SBT_1S))
> + return SBT_MAX;
> +#endif
> + return ((sbintime_t)data << 32);
> case NOTE_MSECONDS: /* FALLTHROUGH */
> case 0:
> - modifier = SBT_1MS;
> - break;
> + if (data >= 1000) {
> + int64_t secs = data / 1000;
> +#ifdef __LP64__
> + if (secs > (SBT_MAX / SBT_1S))
> + return SBT_MAX;
> +#endif
> + return (secs << 32 | MS_TO_SBT(data %
> 1000));
> + }
> + return MS_TO_SBT(data);
> case NOTE_USECONDS:
> - modifier = SBT_1US;
> - break;
> + if (data >= 1000000) {
> + int64_t secs = data / 1000000;
> +#ifdef __LP64__
> + if (secs > (SBT_MAX / SBT_1S))
> + return SBT_MAX;
> +#endif
> + return (secs << 32 | US_TO_SBT(data %
> 1000000));
> + }
> + return US_TO_SBT(data);
> case NOTE_NSECONDS:
> - modifier = SBT_1NS;
> + if (data >= 1000000000) {
> + int64_t secs = data / 1000000000;
> +#ifdef __LP64__
> + if (secs > (SBT_MAX / SBT_1S))
> + return SBT_MAX;
> +#endif
> + return (secs << 32 | US_TO_SBT(data %
> 1000000000));
> + }
> + return NS_TO_SBT(data);
> + default:
> break;
> - default:
> - return (-1);
> }
> -
> -#ifdef __LP64__
> - if (data > SBT_MAX / modifier)
> - return (SBT_MAX);
> -#endif
> - return (modifier * data);
> + return (-1);
> }
>
> static void
> Index: .
> ===================================================================
> --- . (revision 310169)
> +++ . (working copy)
>
> Property changes on: .
> ___________________________________________________________________
> Modified: svn:mergeinfo
> ## -0,0 +0,1 ##
> Merged /head:r296775
> _______________________________________________
Yep, that was the solution. After merging r296775 I now get:
revolution > ./kevent_evfilt_timer
nsec = 10000009129 for 10000 loops of 1000000 nsec
Thanks for tracking that down.
-- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1481931048.1343.2.camel>