[GitHub] incubator-hawq issue #872: HAWQ-1030. Forward PostgreSQL spin lock peformanc...

[paul-guo- <gi...@git.apache.org>]

Github user paul-guo- commented on the issue:

    https://github.com/apache/incubator-hawq/pull/872
  
    The patch is beneficial generally. hawq should include it.
    
    I'm just curious about the upstream implementation of spin lock. This is a bit not related to this patch, but I'd express my option here.
    
    1) pg_usleep() uses the select() way.
    
    Not sure whether the comment still applies to some latest HW and SW, but
    isn't a posix delay syscall nanosleep(), which is with high resoluation better?
    
    +/*
    + * pg_usleep --- delay the specified number of microseconds.
    + *
    + * NOTE: although the delay is specified in microseconds, the effective
    + * resolution is only 1/HZ, or 10 milliseconds, on most Unixen.  Expect
    + * the requested delay to be rounded up to the next resolution boundary.
    + *
    + * On machines where "long" is 32 bits, the maximum delay is ~2000 seconds.
    + */
    +void
    +pg_usleep(long microsec)
    +{
    +       if (microsec > 0)
    +       {
    +#ifndef WIN32
    +               struct timeval delay;
    +
    +               delay.tv_sec = microsec / 1000000L;
    +               delay.tv_usec = microsec % 1000000L;
    +               (void) select(0, NULL, NULL, NULL, &delay);
    +#else
    
    2) spin lock is used for cases that the resource will be released soon, so I guess a sched_yield() after some backoff pause is probably more suitable for spinlock (probably could be combined with some process priority adjustment) since it will reduce the latency, even with some additional cpu cost. If there are cases that could lock for a bit longer, a blocking lock should be implemented/used instead.



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---