Yeah, I figure there's a bit of overhead, even if it's in the constant
sleep()/wakeup context switches alone.
I initially chose 10ms because I think it's close to the OS scheduler's quantum.
I also figure the time should be a bit longer than what I expect typical "long
time running threads" to actually run. "Long time" would be longer than what
you'd do in an event-loop style scheme. And from my experience with SilkJS, I
typically see sub millisecond entire HTTP request CPU times, and requests that
do quite a bit of CPU work take < 10ms, and requests that read in 25 files and
parse them for /** … */ comments and run the content through
github-flavored-wiki can take a second. Those really long running ones would
be scheduled by Unlockers in the C++ code (reading files) anyhow, so it
probably would work out at 10ms. So I figured.
Yet the main thread was clearly starved for CPU cycles….
On Jul 2, 2012, at 1:17 PM, Pablo Sole wrote:
> The ms you set is used here:
>
> void ContextSwitcher::Run() {
> while (keep_going_) {
> OS::Sleep(sleep_ms_);
> isolate()->stack_guard()->Preempt();
> }
> }
>
> So what you're doing basically is to preempt on every preemptible point.
> There might be a better way of doing this without the need of a thread
> constantly setting the PREEMPT flag on the current StackGuard instance
> (several times actually). May be to set the flag ON by default on the
> StackGuard constructor.
>
> Anyway, it's interesting indeed as that would be the fairest
> distribution possible from an engine perspective, may be somebody from
> the engine team can tell us more accurately what's the overhead involved
> in a preemption task switch.
>
> pablo.
>
> On 07/02/2012 04:34 PM, Michael Schwartz wrote:
>> You might find this interesting.
>>
>> I tried setting preemption time to 10ms and output of my script was sporadic
>> (in bursts). I set it to 1ms and it got way better. I set it to 0ms and it
>> seems perfect.
>>
>> I'm not sure what kind of performance impact this setting has.
>>
>> On Jul 2, 2012, at 10:52 AM, Pablo Sole wrote:
>>
>>> On 07/02/2012 01:00 PM, Michael Schwartz wrote:
>>>> Wow, that's a great tip. I implemented it and long running threads work
>>>> fine and get preempted.
>>> Glad to help!
>>>> I guess the disadvantage is thread safety and synchronization of data
>>>> accesses. I'm not clear on when a thread running in v8 might be
>>>> preempted. Likely on entering or exiting functions (when doing stack
>>>> checks, I think I remember reading about).
>>> AFAIK, any StackGuard instance is preemptible, regex matching also check
>>> for preemption, some loops and there must be some other places too. This
>>> mechanism is used by chromium, I suppose, to switch between Contexts
>>> (frames/iframes) of a same tab (Isolate?). I'm completely making this up
>>> and it's probably not accurate, but must be something like that :).
>>>
>>> The rule of thumb for thread safety should be to not trust on a Locker
>>> instance (which can be preempted) for any resource sync managed or
>>> potentially modified from outside of v8. A C++ function wrapped inside a
>>> FunctionTemplate though, cannot be preempted of course, so that's safe.
>>>
>>> pablo.
>>>
>>> --
>>> v8-users mailing list
>>> [email protected]
>>> http://groups.google.com/group/v8-users
>
>
> --
> v8-users mailing list
> [email protected]
> http://groups.google.com/group/v8-users
--
v8-users mailing list
[email protected]
http://groups.google.com/group/v8-users
