On 2017-07-02 18:54, John Nemeth wrote:
On Jul 2, 1:16pm, Christos Zoulas wrote:
} In article <1n8j63y.1pcs0owrn6gcem%[email protected]>,
} Emmanuel Dreyfus <[email protected]> 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
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: [email protected] || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
