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.
I don't get it. What was the problem with using nanosleep for short
usleep's?
Also, how does tickless mode help?
This is all about the current implementation of usleep, which suspends
the thread, and the time slice the scheduler uses between context
switches. A tickless implementation will still split processing time
into time slices between context switches, so you'd still get the same
effect with a tickless kernel. You just wouldn't get the regular
interrupt at each tick with tickless, since that is actually what
tickless mode is about (unless I'm confused). With tickless mode, you
instead keep track of time through other means than a regular clock
interrupt, which might do nothing more than increment the time.
And I fail to see how it would be a problem implementing usleep using
nanosleep for short time values. In fact, OSX as an example, uses
nanosleep for all usleep calls.
You still have the caveat that suspension might be longer. The time
argument actually just gives a lower bound. But OSX obviously uses
nanosleep for this scenario.
(Yes, I might totally have missed some earlier discussion on this topic,
and might be totally bonkers and clueless. In which case, feel free to
educate me.)
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
