On 2017-07-02 18:54, John Nemeth wrote:
On Jul 2, 1:16pm, Christos Zoulas wrote:
} In article <1n8j63y.1pcs0owrn6gceM%manu%netbsd.org@localhost>,
} Emmanuel Dreyfus <manu%netbsd.org@localhost> 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: bqt%softjar.se@localhost || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol