Date: Tue, 6 Sep 2011 21:15:55 -0400 From: Rayson Ho <raysonlogin@gmail.com> To: freebsd-hackers@freebsd.org Subject: Re: excessive use of gettimeofday(2) and other syscalls Message-ID: <CAHwLALMwOu8wc5W03dar5fhkWkjN6f7eDGAT4a1u%2BK4eHHSsng@mail.gmail.com> In-Reply-To: <CAHRgBhT%2BKi%2BYPiK%2Bhn=fJ91eA=31tOaTPe_5xLSHQawa=%2BFD0Q@mail.gmail.com> References: <20110906220115.GA25048@freebsd.org> <CAHRgBhRe8n%2BV3nSzRn4_fctHB1nie2ACk7oRVOPJqqKaMUgKrg@mail.gmail.com> <CAF6rxg=kzHP4zr_=LGnJDUQu-xEwgpy6QN=Lk4jqXa6hs=epKg@mail.gmail.com> <CAHRgBhT%2BKi%2BYPiK%2Bhn=fJ91eA=31tOaTPe_5xLSHQawa=%2BFD0Q@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
There are some recent discussions on the freebsd-current list. The infrastructure is there to provide a common shared page for processes to mmap into the address space... but according to Kip's comment, libc support is not there yet: http://lists.freebsd.org/pipermail/freebsd-current/2011-June/025191.html Also, the kernel needs to update the variable in that shared page on each clock interrupt (depending on the resolution I believe), and I think that needs to be added too. IMO, the time returned by gettimeofday does not need to be high precision. There are higher resolution time APIs on Linux and I believe the application programmers know when to use the slower but more accurate clock API. (At least in Grid Engine we only need a quick way of getting the current time, and we don't care if it is precise to the nanosecond range.) See Linux security issue & solution: http://lwn.net/Articles/446528/ See also the Google SoC idea: http://wiki.freebsd.org/IdeasPage#Timecounter_Performance_Improvements_.28G= SoC.29 Rayson =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D Grid Engine / Open Grid Scheduler http://gridscheduler.sourceforge.net On Tue, Sep 6, 2011 at 8:49 PM, Manish Vachharajani <manishv@lineratesystems.com> wrote: > I believe that Linux uses a less precise clock that scales better > across cores and is much faster than the precise clock FreeBSD uses > even on one core. =A0I don't know POSIX and other standards well enough > to know if this is an acceptable solution on FreeBSD. =A0However, there > are less precise clocks on FreeBSD that are considerably faster (i.e., > the _FAST variants). =A0Someone with more expertise in these matters > needs to comment on whether a change to using a _FAST clock is > appropriate in libc. =A0If it is acceptable, I think that it is easier > to just make time use the FAST clock instead of getting programmers to > change their programs. > > On Tue, Sep 6, 2011 at 6:41 PM, Eitan Adler <lists@eitanadler.com> wrote: >> On Tue, Sep 6, 2011 at 6:44 PM, Manish Vachharajani >> <manishv@lineratesystems.com> wrote: >>> Lots of libraries assume that time is fast because it >>> is fast under Linux. >> >> Silly question, but why can't we make it fast too? >> >> -- >> Eitan Adler >> > > Manish > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org= " > --=20 Rayson =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Open Grid Scheduler - The Official Open Source Grid Engine http://gridscheduler.sourceforge.net/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAHwLALMwOu8wc5W03dar5fhkWkjN6f7eDGAT4a1u%2BK4eHHSsng>