CLOCK_BOOTIME (commit cf87f8587)

[Christof Schmitt]

On Sat, Aug 13, 2016 at 08:55:06AM +0200, Ralph Böhme wrote:
> Hi!
> 
> Simo wrote:
> > On Mon, Aug 01, 2016 at 03:00:16PM +0200, Volker Lendecke wrote:
> > > Just talked to Björn Jacke: He told me that commit cf87f8587 was
> > > triggered by a suggestion you made. CLOCK_BOOTTIME is the better
> > > alternative than CLOCK_MONOTONIC. I don't fully understand it, but
> > > what I get is that CLOCK_BOOTTIME correctly takes care of a machine in
> > > suspend mode.
> > > 
> > > This of course makes a lot of sense for laptops, but it comes at
> > > a cost: If I run the attached program on a PPC machine I get that
> > > calling CLOCK_BOOTTIME is roughly 8 times more expensive than calling
> > > CLOCK_MONOTONIC. Christof Schmitt has figured out that this is due to
> > > CLOCK_BOOTTIME being a real syscall whereas CLOCK_MONOTONIC is a pure
> > > read from a kernel page like getpid() is.
> > > 
> > > [root at p8-10-rhel-71be-01 vlendeke]# time ./timetest 100000000
> > > real    0m26.443s
> > > user    0m7.298s
> > > sys     0m19.145s
> > > [root at p8-10-rhel-71be-01 vlendeke]# time ./timetest 100000000 mono
> > > real    0m3.253s
> > > user    0m3.244s
> > > sys     0m0.010s
> > > 
> > > Simo, do you really see the need for CLOCK_BOOTTIME for your RHEL
> > > deployments? Or could you live with CLOCK_MONOTONIC only?
> > > 
> > > If your customers need CLOCK_BOOTTIME, has RedHat the capability to
> > > make CLOCK_BOOTTIME a kernel page read too, so that it is just as
> > > cheap as CLOCK_MONOTONIC?
> > 
> > Hi Volker,
> > I think it is fine to use clock monotonic in the file server, the main reason
> > to use clock boottime was for winbind when used on laptops indeed.
> > 
> > If it is possible to use one for the file server and the other for winbindd
> > that would be nice, otherwise feel free to switch to monotonic.
> 
> would a build time option help? Something like the attached?
> 
> We want to add any overhead at runtime to clock_gettime_mono(), so I
> don't see a way of making this a runtime option.

That would be one option. The other thought would be having a second
function clock_gettime_boottime and use that in codepaths reachable from
winbindd, and keep using clock_gettime_mono from smbd (mainly
vfs_time_audit and profiling). I have not looked enough into the details
to say whether that would be feasible.

Christof