tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: nanosleep() for shorted than schedule slice

On 2017-07-02 18:54, John Nemeth wrote:
On Jul 2,  1:16pm, Christos Zoulas wrote:
} In article <>,
} Emmanuel Dreyfus <> wrote:
} >
} >I just encountered a situation where PHP performance on NetBSD is rather
} >weak compared to Linux or MacOS X.
} >
} >The code calls PHP's uniqid() a lot of time. uniqid() creates an unique
} >id based on the clock. In order to avoid giving the same value for two
} >consecutive calls, PHP's uniqid() calls usleep(1) to skip to make sure
} >the current microsecond has changed.
} >
} >On NetBSD this turns into a 16 ms sleep, which is 16000 what was
} >requested. This happens because the kernel scheduled another process,
} >which is the behavior documented in the man page. However the result is
} >that a PHP script full of uniqid() is ridiculously slow.
} >
} >I worked around the problem by reimplementing PHP uniqid() using
} >uuidgen(), but that kind of performance problem could exist in many
} >other softwares.
} >
} >I wonder if it would make sense for nanosleep(2) to check that requested
} >sleeping time is shorter than a schedule slice, and if it is, spin the
} >CPU instead of scheduling another process. Any opinion on this?
} The solution is to implement "tickless kernel". It is not that difficult.

      The other option would be to tell PHP not to be so dumb.  What
happens on other OSes?  I find it hard to believe that we're the
only ones that aren't tickless.

One more reply in addition to my previous one. As I said, OSX for example, do use nanosleep.

But I just checked a little more in NetBSD, and it would seem that the man-page for nanosleep actually claims that our nanosleep is in fact using the normal clock ticks as well, giving nanosleep a resolution of (normally) 10ms. Which seems absurd. Are we really giving that poor resolution to nanosleep calls? I would still say that this is not necessarily tied to a tickless implementation, even if I can see that there is a connection here. We should be able to deal with very high resolution clocks, even if we have a normal clock ticking at 100Hz. But it might be easiest if we were to move to a tickless implementation in general, in order to deal with arbitrary clock times.


Johnny Billquist                  || "I'm on a bus
                                  ||  on a psychedelic trip
email:             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol

Home | Main Index | Thread Index | Old Index