RepoMirrors/haproxy
1
0
Fork 0
mirror of http://git.haproxy.org/git/haproxy.git/ synced 2024-12-18 09:24:31 +00:00
Code Issues Packages Projects Releases Wiki Activity
99e0bb997f
haproxy/src/freq_ctr.c

278 lines
7.6 KiB
C
Raw Normal View History

[MEDIUM] measure and report session rate on frontend, backends and servers With this change, all frontends, backends, and servers maintain a session counter and a timer to compute a session rate over the last second. This value will be very useful because it varies instantly and can be used to check thresholds. This value is also reported in the stats in a new "rate" column.
2009-03-05 17:43:00 +00:00
/*
* Event rate calculation functions.
*
[MINOR] freq_ctr: add new types and functions for periods different from 1s Some freq counters will have to work on periods different from 1 second. The original freq counters rely on the period to be exactly one second. The new ones (freq_ctr_period) let the user define the period in ticks, and all computations are operated over that period. When reading a value, it indicates the amount of events over that period too.
2010-06-20 05:15:43 +00:00
* Copyright 2000-2010 Willy Tarreau <w@1wt.eu>
[MEDIUM] measure and report session rate on frontend, backends and servers With this change, all frontends, backends, and servers maintain a session counter and a timer to compute a session rate over the last second. This value will be very useful because it varies instantly and can be used to check thresholds. This value is also reported in the stats in a new "rate" column.
2009-03-05 17:43:00 +00:00
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License
* as published by the Free Software Foundation; either version
* 2 of the License, or (at your option) any later version.
*
*/
REORG: include: update all files to use haproxy/api.h or api-t.h if needed All files that were including one of the following include files have been updated to only include haproxy/api.h or haproxy/api-t.h once instead: - common/config.h - common/compat.h - common/compiler.h - common/defaults.h - common/initcall.h - common/tools.h The choice is simple: if the file only requires type definitions, it includes api-t.h, otherwise it includes the full api.h. In addition, in these files, explicit includes for inttypes.h and limits.h were dropped since these are now covered by api.h and api-t.h. No other change was performed, given that this patch is large and affects 201 files. At least one (tools.h) was already freestanding and didn't get the new one added.
2020-05-27 10:58:42 +00:00
#include <haproxy/api.h>
REORG: include: move freq_ctr to haproxy/ types/freq_ctr.h was moved to haproxy/freq_ctr-t.h and proto/freq_ctr.h was moved to haproxy/freq_ctr.h. Files were updated accordingly, no other change was applied.
2020-06-01 10:18:08 +00:00
#include <haproxy/freq_ctr.h>
CLEANUP: include: tree-wide alphabetical sort of include files This patch fixes all the leftovers from the include cleanup campaign. There were not that many (~400 entries in ~150 files) but it was definitely worth doing it as it revealed a few duplicates.
2020-06-09 07:07:15 +00:00
#include <haproxy/time.h>
#include <haproxy/tools.h>
[MEDIUM] measure and report session rate on frontend, backends and servers With this change, all frontends, backends, and servers maintain a session counter and a timer to compute a session rate over the last second. This value will be very useful because it varies instantly and can be used to check thresholds. This value is also reported in the stats in a new "rate" column.
2009-03-05 17:43:00 +00:00
/* Read a frequency counter taking history into account for missing time in
* current period. Current second is sub-divided in 1000 chunks of one ms,
* and the missing ones are read proportionally from previous value. The
* return value has the same precision as one input data sample, so low rates
* will be inaccurate still appropriate for max checking. One trick we use for
* low values is to specially handle the case where the rate is between 0 and 1
* in order to avoid flapping while waiting for the next event.
[OPTIM] rate-limit: cleaner behaviour on low rates and reduce consumption The rate-limit was applied to the smoothed value which does a special case for frequencies below 2 events per period. This caused irregular limitations when set to 1 session per second. The proper way to handle this is to compute the number of remaining events that can occur without reaching the limit. This is what has been added. It also has the benefit that the frequency calculation is now done once when entering event_accept(), before the accept() loop, and not once per accept() loop anymore, thus saving a few CPU cycles during very high loads. With this fix, rate limits of 1/s are perfectly respected.
2009-03-06 08:18:27 +00:00
*
* For immediate limit checking, it's recommended to use freq_ctr_remain() and
* next_event_delay() instead which do not have the flapping correction, so
* that even frequencies as low as one event/period are properly handled.
[MEDIUM] measure and report session rate on frontend, backends and servers With this change, all frontends, backends, and servers maintain a session counter and a timer to compute a session rate over the last second. This value will be very useful because it varies instantly and can be used to check thresholds. This value is also reported in the stats in a new "rate" column.
2009-03-05 17:43:00 +00:00
*/
unsigned int read_freq_ctr(struct freq_ctr *ctr)
{
BUG/MAJOR: threads/freq_ctr: fix lock on freq counters. The wrong bit was set to keep the lock on freq counter update. And the read functions were re-worked to use volatile. Moreover, when a freq counter is updated, it is now rotated only if the current counter is in the past (now.tv_sec > ctr->curr_sec). It is important with threads because the current time (now) is thread-local. So, rounded to the second, the time may vary by more or less 1 second. So a freq counter rotated by one thread may be see 1 second in the future. In this case, it is updated but not rotated.
2017-10-30 17:04:28 +00:00
unsigned int curr, past, _curr, _past;
unsigned int age, curr_sec, _curr_sec;
BUG/MAJOR: threads/freq_ctr: use a memory barrier to detect changes commit 6e01286 (BUG/MAJOR: threads/freq_ctr: fix lock on freq counters) attempted to fix the loop using volatile but that doesn't work depending on the level of optimization, resulting in situations where the threads could remain looping forever. Here we use memory barriers between reads to enforce a strict ordering and the asm code produced does exactly what the C code does and works perfectly, with a 3-digit measurement accuracy observed during a test.
2017-10-31 16:54:15 +00:00
while (1) {
_curr = ctr->curr_ctr;
REORG: threads: extract atomic ops from hathreads.h The hathreads.h file has quickly become a total mess because it contains thread definitions, atomic operations and locking operations, all this for multiple combinations of threads, debugging and architectures, and all this done with random ordering! This first patch extracts all the atomic ops code from hathreads.h to move it to haproxy/atomic.h. The code there still contains several sections based on non-thread vs thread, and GCC versions in the latter case. Each section was arranged in the exact same order to ease finding. The redundant HA_BARRIER() which was the same as __ha_compiler_barrier() was dropped in favor of the latter which follows the naming convention of all other barriers. It was only used in freq_ctr.c which was updated. Additionally, __ha_compiler_barrier() was defined inconditionally but used only for thread-related operations, so it was made thread-only like HA_BARRIER() used to be. We'd still need to have two types of compiler barriers, one for the general case (e.g. signals) and another one for concurrency, but this was not addressed here. Some comments were added at the beginning of each section to inform about the use case and warn about the traps to avoid. Some files which continue to include hathreads.h solely for atomic ops should now be updated.
2020-05-28 13:29:33 +00:00
__ha_compiler_barrier();
BUG/MAJOR: threads/freq_ctr: use a memory barrier to detect changes commit 6e01286 (BUG/MAJOR: threads/freq_ctr: fix lock on freq counters) attempted to fix the loop using volatile but that doesn't work depending on the level of optimization, resulting in situations where the threads could remain looping forever. Here we use memory barriers between reads to enforce a strict ordering and the asm code produced does exactly what the C code does and works perfectly, with a 3-digit measurement accuracy observed during a test.
2017-10-31 16:54:15 +00:00
_past = ctr->prev_ctr;
REORG: threads: extract atomic ops from hathreads.h The hathreads.h file has quickly become a total mess because it contains thread definitions, atomic operations and locking operations, all this for multiple combinations of threads, debugging and architectures, and all this done with random ordering! This first patch extracts all the atomic ops code from hathreads.h to move it to haproxy/atomic.h. The code there still contains several sections based on non-thread vs thread, and GCC versions in the latter case. Each section was arranged in the exact same order to ease finding. The redundant HA_BARRIER() which was the same as __ha_compiler_barrier() was dropped in favor of the latter which follows the naming convention of all other barriers. It was only used in freq_ctr.c which was updated. Additionally, __ha_compiler_barrier() was defined inconditionally but used only for thread-related operations, so it was made thread-only like HA_BARRIER() used to be. We'd still need to have two types of compiler barriers, one for the general case (e.g. signals) and another one for concurrency, but this was not addressed here. Some comments were added at the beginning of each section to inform about the use case and warn about the traps to avoid. Some files which continue to include hathreads.h solely for atomic ops should now be updated.
2020-05-28 13:29:33 +00:00
__ha_compiler_barrier();
BUG/MAJOR: threads/freq_ctr: use a memory barrier to detect changes commit 6e01286 (BUG/MAJOR: threads/freq_ctr: fix lock on freq counters) attempted to fix the loop using volatile but that doesn't work depending on the level of optimization, resulting in situations where the threads could remain looping forever. Here we use memory barriers between reads to enforce a strict ordering and the asm code produced does exactly what the C code does and works perfectly, with a 3-digit measurement accuracy observed during a test.
2017-10-31 16:54:15 +00:00
_curr_sec = ctr->curr_sec;
REORG: threads: extract atomic ops from hathreads.h The hathreads.h file has quickly become a total mess because it contains thread definitions, atomic operations and locking operations, all this for multiple combinations of threads, debugging and architectures, and all this done with random ordering! This first patch extracts all the atomic ops code from hathreads.h to move it to haproxy/atomic.h. The code there still contains several sections based on non-thread vs thread, and GCC versions in the latter case. Each section was arranged in the exact same order to ease finding. The redundant HA_BARRIER() which was the same as __ha_compiler_barrier() was dropped in favor of the latter which follows the naming convention of all other barriers. It was only used in freq_ctr.c which was updated. Additionally, __ha_compiler_barrier() was defined inconditionally but used only for thread-related operations, so it was made thread-only like HA_BARRIER() used to be. We'd still need to have two types of compiler barriers, one for the general case (e.g. signals) and another one for concurrency, but this was not addressed here. Some comments were added at the beginning of each section to inform about the use case and warn about the traps to avoid. Some files which continue to include hathreads.h solely for atomic ops should now be updated.
2020-05-28 13:29:33 +00:00
__ha_compiler_barrier();
BUG/MAJOR: threads/freq_ctr: fix lock on freq counters. The wrong bit was set to keep the lock on freq counter update. And the read functions were re-worked to use volatile. Moreover, when a freq counter is updated, it is now rotated only if the current counter is in the past (now.tv_sec > ctr->curr_sec). It is important with threads because the current time (now) is thread-local. So, rounded to the second, the time may vary by more or less 1 second. So a freq counter rotated by one thread may be see 1 second in the future. In this case, it is updated but not rotated.
2017-10-30 17:04:28 +00:00
if (_curr_sec & 0x80000000)
continue;
BUG/MAJOR: threads/freq_ctr: use a memory barrier to detect changes commit 6e01286 (BUG/MAJOR: threads/freq_ctr: fix lock on freq counters) attempted to fix the loop using volatile but that doesn't work depending on the level of optimization, resulting in situations where the threads could remain looping forever. Here we use memory barriers between reads to enforce a strict ordering and the asm code produced does exactly what the C code does and works perfectly, with a 3-digit measurement accuracy observed during a test.
2017-10-31 16:54:15 +00:00
curr = ctr->curr_ctr;
REORG: threads: extract atomic ops from hathreads.h The hathreads.h file has quickly become a total mess because it contains thread definitions, atomic operations and locking operations, all this for multiple combinations of threads, debugging and architectures, and all this done with random ordering! This first patch extracts all the atomic ops code from hathreads.h to move it to haproxy/atomic.h. The code there still contains several sections based on non-thread vs thread, and GCC versions in the latter case. Each section was arranged in the exact same order to ease finding. The redundant HA_BARRIER() which was the same as __ha_compiler_barrier() was dropped in favor of the latter which follows the naming convention of all other barriers. It was only used in freq_ctr.c which was updated. Additionally, __ha_compiler_barrier() was defined inconditionally but used only for thread-related operations, so it was made thread-only like HA_BARRIER() used to be. We'd still need to have two types of compiler barriers, one for the general case (e.g. signals) and another one for concurrency, but this was not addressed here. Some comments were added at the beginning of each section to inform about the use case and warn about the traps to avoid. Some files which continue to include hathreads.h solely for atomic ops should now be updated.
2020-05-28 13:29:33 +00:00
__ha_compiler_barrier();
BUG/MAJOR: threads/freq_ctr: use a memory barrier to detect changes commit 6e01286 (BUG/MAJOR: threads/freq_ctr: fix lock on freq counters) attempted to fix the loop using volatile but that doesn't work depending on the level of optimization, resulting in situations where the threads could remain looping forever. Here we use memory barriers between reads to enforce a strict ordering and the asm code produced does exactly what the C code does and works perfectly, with a 3-digit measurement accuracy observed during a test.
2017-10-31 16:54:15 +00:00
past = ctr->prev_ctr;
REORG: threads: extract atomic ops from hathreads.h The hathreads.h file has quickly become a total mess because it contains thread definitions, atomic operations and locking operations, all this for multiple combinations of threads, debugging and architectures, and all this done with random ordering! This first patch extracts all the atomic ops code from hathreads.h to move it to haproxy/atomic.h. The code there still contains several sections based on non-thread vs thread, and GCC versions in the latter case. Each section was arranged in the exact same order to ease finding. The redundant HA_BARRIER() which was the same as __ha_compiler_barrier() was dropped in favor of the latter which follows the naming convention of all other barriers. It was only used in freq_ctr.c which was updated. Additionally, __ha_compiler_barrier() was defined inconditionally but used only for thread-related operations, so it was made thread-only like HA_BARRIER() used to be. We'd still need to have two types of compiler barriers, one for the general case (e.g. signals) and another one for concurrency, but this was not addressed here. Some comments were added at the beginning of each section to inform about the use case and warn about the traps to avoid. Some files which continue to include hathreads.h solely for atomic ops should now be updated.
2020-05-28 13:29:33 +00:00
__ha_compiler_barrier();
BUG/MAJOR: threads/freq_ctr: use a memory barrier to detect changes commit 6e01286 (BUG/MAJOR: threads/freq_ctr: fix lock on freq counters) attempted to fix the loop using volatile but that doesn't work depending on the level of optimization, resulting in situations where the threads could remain looping forever. Here we use memory barriers between reads to enforce a strict ordering and the asm code produced does exactly what the C code does and works perfectly, with a 3-digit measurement accuracy observed during a test.
2017-10-31 16:54:15 +00:00
curr_sec = ctr->curr_sec;
REORG: threads: extract atomic ops from hathreads.h The hathreads.h file has quickly become a total mess because it contains thread definitions, atomic operations and locking operations, all this for multiple combinations of threads, debugging and architectures, and all this done with random ordering! This first patch extracts all the atomic ops code from hathreads.h to move it to haproxy/atomic.h. The code there still contains several sections based on non-thread vs thread, and GCC versions in the latter case. Each section was arranged in the exact same order to ease finding. The redundant HA_BARRIER() which was the same as __ha_compiler_barrier() was dropped in favor of the latter which follows the naming convention of all other barriers. It was only used in freq_ctr.c which was updated. Additionally, __ha_compiler_barrier() was defined inconditionally but used only for thread-related operations, so it was made thread-only like HA_BARRIER() used to be. We'd still need to have two types of compiler barriers, one for the general case (e.g. signals) and another one for concurrency, but this was not addressed here. Some comments were added at the beginning of each section to inform about the use case and warn about the traps to avoid. Some files which continue to include hathreads.h solely for atomic ops should now be updated.
2020-05-28 13:29:33 +00:00
__ha_compiler_barrier();
BUG/MAJOR: threads/freq_ctr: fix lock on freq counters. The wrong bit was set to keep the lock on freq counter update. And the read functions were re-worked to use volatile. Moreover, when a freq counter is updated, it is now rotated only if the current counter is in the past (now.tv_sec > ctr->curr_sec). It is important with threads because the current time (now) is thread-local. So, rounded to the second, the time may vary by more or less 1 second. So a freq counter rotated by one thread may be see 1 second in the future. In this case, it is updated but not rotated.
2017-10-30 17:04:28 +00:00
if (_curr == curr && _past == past && _curr_sec == curr_sec)
break;
}
MEDIUM: threads/freq_ctr: Make the frequency counters thread-safe When a frequency counter must be updated, we use the curr_sec/curr_tick fields as a lock, by setting the MSB to 1 in a compare-and-swap to lock and by reseting it to unlock. And when we need to read it, we loop until the counter is unlocked. This way, the frequency counters are thread-safe without any external lock. It is important to avoid increasing the size of many structures (global, proxy, server, stick_table).
2017-10-12 07:49:09 +00:00
age = now.tv_sec - curr_sec;
[OPTIM] freq_ctr: do not rotate the counters when reading It's easier to take the counter's age into account when consulting it than to rotate it first. It also saves some CPU cycles and avoids the multiply for outdated counters, finally saving CPU cycles here too when multiple operations need to read the same counter. The freq_ctr code has also shrinked by one third consecutively to these optimizations.
2009-03-06 13:29:25 +00:00
if (unlikely(age > 1))
return 0;
MEDIUM: threads/freq_ctr: Make the frequency counters thread-safe When a frequency counter must be updated, we use the curr_sec/curr_tick fields as a lock, by setting the MSB to 1 in a compare-and-swap to lock and by reseting it to unlock. And when we need to read it, we loop until the counter is unlocked. This way, the frequency counters are thread-safe without any external lock. It is important to avoid increasing the size of many structures (global, proxy, server, stick_table).
2017-10-12 07:49:09 +00:00
if (unlikely(age)) {
past = curr;
curr = 0;
[OPTIM] freq_ctr: do not rotate the counters when reading It's easier to take the counter's age into account when consulting it than to rotate it first. It also saves some CPU cycles and avoids the multiply for outdated counters, finally saving CPU cycles here too when multiple operations need to read the same counter. The freq_ctr code has also shrinked by one third consecutively to these optimizations.
2009-03-06 13:29:25 +00:00
}
[MEDIUM] measure and report session rate on frontend, backends and servers With this change, all frontends, backends, and servers maintain a session counter and a timer to compute a session rate over the last second. This value will be very useful because it varies instantly and can be used to check thresholds. This value is also reported in the stats in a new "rate" column.
2009-03-05 17:43:00 +00:00
[OPTIM] freq_ctr: do not rotate the counters when reading It's easier to take the counter's age into account when consulting it than to rotate it first. It also saves some CPU cycles and avoids the multiply for outdated counters, finally saving CPU cycles here too when multiple operations need to read the same counter. The freq_ctr code has also shrinked by one third consecutively to these optimizations.
2009-03-06 13:29:25 +00:00
if (past <= 1 && !curr)
return past; /* very low rate, avoid flapping */
BUG/MINOR: time: frequency counters are not totally accurate When a frontend is rate-limited to 1000 connections per second, the effective rate measured from the client is 999/s, and connections experience an average response time of 99.5 ms with a standard deviation of 2 ms. The reason for this inaccuracy is that when computing frequency counters, we use one part of the previous value proportional to the number of milliseconds remaining in the current second. But even the last millisecond still uses a part of the past value, which is wrong : since we have a 1ms resolution, the last millisecond must be dedicated only to filling the current second. So we slightly adjust the algorithm to use 999/1000 of the past value during the first millisecond, and 0/1000 of the past value during the last millisecond. We also slightly improve the computation by computing the remaining time instead of the current time in tv_update_date(), so that we don't have to negate the value in each frequency counter. Now with the fix, the connection rate measured by both the client and haproxy is a steady 1000/s, the average response time measured is 99.2ms and more importantly, the standard deviation has been divided by 3 to 0.6 millisecond. This fix should also be backported to 1.4 which has the same issue.
2012-12-29 20:50:07 +00:00
return curr + mul32hi(past, ms_left_scaled);
[MEDIUM] measure and report session rate on frontend, backends and servers With this change, all frontends, backends, and servers maintain a session counter and a timer to compute a session rate over the last second. This value will be very useful because it varies instantly and can be used to check thresholds. This value is also reported in the stats in a new "rate" column.
2009-03-05 17:43:00 +00:00
}
[OPTIM] rate-limit: cleaner behaviour on low rates and reduce consumption The rate-limit was applied to the smoothed value which does a special case for frequencies below 2 events per period. This caused irregular limitations when set to 1 session per second. The proper way to handle this is to compute the number of remaining events that can occur without reaching the limit. This is what has been added. It also has the benefit that the frequency calculation is now done once when entering event_accept(), before the accept() loop, and not once per accept() loop anymore, thus saving a few CPU cycles during very high loads. With this fix, rate limits of 1/s are perfectly respected.
2009-03-06 08:18:27 +00:00
/* returns the number of remaining events that can occur on this freq counter
* while respecting <freq> and taking into account that <pend> events are
* already known to be pending. Returns 0 if limit was reached.
*/
unsigned int freq_ctr_remain(struct freq_ctr *ctr, unsigned int freq, unsigned int pend)
{
BUG/MAJOR: threads/freq_ctr: fix lock on freq counters. The wrong bit was set to keep the lock on freq counter update. And the read functions were re-worked to use volatile. Moreover, when a freq counter is updated, it is now rotated only if the current counter is in the past (now.tv_sec > ctr->curr_sec). It is important with threads because the current time (now) is thread-local. So, rounded to the second, the time may vary by more or less 1 second. So a freq counter rotated by one thread may be see 1 second in the future. In this case, it is updated but not rotated.
2017-10-30 17:04:28 +00:00
unsigned int curr, past, _curr, _past;
unsigned int age, curr_sec, _curr_sec;
BUG/MAJOR: threads/freq_ctr: use a memory barrier to detect changes commit 6e01286 (BUG/MAJOR: threads/freq_ctr: fix lock on freq counters) attempted to fix the loop using volatile but that doesn't work depending on the level of optimization, resulting in situations where the threads could remain looping forever. Here we use memory barriers between reads to enforce a strict ordering and the asm code produced does exactly what the C code does and works perfectly, with a 3-digit measurement accuracy observed during a test.
2017-10-31 16:54:15 +00:00
while (1) {
_curr = ctr->curr_ctr;
REORG: threads: extract atomic ops from hathreads.h The hathreads.h file has quickly become a total mess because it contains thread definitions, atomic operations and locking operations, all this for multiple combinations of threads, debugging and architectures, and all this done with random ordering! This first patch extracts all the atomic ops code from hathreads.h to move it to haproxy/atomic.h. The code there still contains several sections based on non-thread vs thread, and GCC versions in the latter case. Each section was arranged in the exact same order to ease finding. The redundant HA_BARRIER() which was the same as __ha_compiler_barrier() was dropped in favor of the latter which follows the naming convention of all other barriers. It was only used in freq_ctr.c which was updated. Additionally, __ha_compiler_barrier() was defined inconditionally but used only for thread-related operations, so it was made thread-only like HA_BARRIER() used to be. We'd still need to have two types of compiler barriers, one for the general case (e.g. signals) and another one for concurrency, but this was not addressed here. Some comments were added at the beginning of each section to inform about the use case and warn about the traps to avoid. Some files which continue to include hathreads.h solely for atomic ops should now be updated.
2020-05-28 13:29:33 +00:00
__ha_compiler_barrier();
BUG/MAJOR: threads/freq_ctr: use a memory barrier to detect changes commit 6e01286 (BUG/MAJOR: threads/freq_ctr: fix lock on freq counters) attempted to fix the loop using volatile but that doesn't work depending on the level of optimization, resulting in situations where the threads could remain looping forever. Here we use memory barriers between reads to enforce a strict ordering and the asm code produced does exactly what the C code does and works perfectly, with a 3-digit measurement accuracy observed during a test.
2017-10-31 16:54:15 +00:00
_past = ctr->prev_ctr;
REORG: threads: extract atomic ops from hathreads.h The hathreads.h file has quickly become a total mess because it contains thread definitions, atomic operations and locking operations, all this for multiple combinations of threads, debugging and architectures, and all this done with random ordering! This first patch extracts all the atomic ops code from hathreads.h to move it to haproxy/atomic.h. The code there still contains several sections based on non-thread vs thread, and GCC versions in the latter case. Each section was arranged in the exact same order to ease finding. The redundant HA_BARRIER() which was the same as __ha_compiler_barrier() was dropped in favor of the latter which follows the naming convention of all other barriers. It was only used in freq_ctr.c which was updated. Additionally, __ha_compiler_barrier() was defined inconditionally but used only for thread-related operations, so it was made thread-only like HA_BARRIER() used to be. We'd still need to have two types of compiler barriers, one for the general case (e.g. signals) and another one for concurrency, but this was not addressed here. Some comments were added at the beginning of each section to inform about the use case and warn about the traps to avoid. Some files which continue to include hathreads.h solely for atomic ops should now be updated.
2020-05-28 13:29:33 +00:00
__ha_compiler_barrier();
BUG/MAJOR: threads/freq_ctr: use a memory barrier to detect changes commit 6e01286 (BUG/MAJOR: threads/freq_ctr: fix lock on freq counters) attempted to fix the loop using volatile but that doesn't work depending on the level of optimization, resulting in situations where the threads could remain looping forever. Here we use memory barriers between reads to enforce a strict ordering and the asm code produced does exactly what the C code does and works perfectly, with a 3-digit measurement accuracy observed during a test.
2017-10-31 16:54:15 +00:00
_curr_sec = ctr->curr_sec;
REORG: threads: extract atomic ops from hathreads.h The hathreads.h file has quickly become a total mess because it contains thread definitions, atomic operations and locking operations, all this for multiple combinations of threads, debugging and architectures, and all this done with random ordering! This first patch extracts all the atomic ops code from hathreads.h to move it to haproxy/atomic.h. The code there still contains several sections based on non-thread vs thread, and GCC versions in the latter case. Each section was arranged in the exact same order to ease finding. The redundant HA_BARRIER() which was the same as __ha_compiler_barrier() was dropped in favor of the latter which follows the naming convention of all other barriers. It was only used in freq_ctr.c which was updated. Additionally, __ha_compiler_barrier() was defined inconditionally but used only for thread-related operations, so it was made thread-only like HA_BARRIER() used to be. We'd still need to have two types of compiler barriers, one for the general case (e.g. signals) and another one for concurrency, but this was not addressed here. Some comments were added at the beginning of each section to inform about the use case and warn about the traps to avoid. Some files which continue to include hathreads.h solely for atomic ops should now be updated.
2020-05-28 13:29:33 +00:00
__ha_compiler_barrier();
BUG/MAJOR: threads/freq_ctr: fix lock on freq counters. The wrong bit was set to keep the lock on freq counter update. And the read functions were re-worked to use volatile. Moreover, when a freq counter is updated, it is now rotated only if the current counter is in the past (now.tv_sec > ctr->curr_sec). It is important with threads because the current time (now) is thread-local. So, rounded to the second, the time may vary by more or less 1 second. So a freq counter rotated by one thread may be see 1 second in the future. In this case, it is updated but not rotated.
2017-10-30 17:04:28 +00:00
if (_curr_sec & 0x80000000)
continue;
BUG/MAJOR: threads/freq_ctr: use a memory barrier to detect changes commit 6e01286 (BUG/MAJOR: threads/freq_ctr: fix lock on freq counters) attempted to fix the loop using volatile but that doesn't work depending on the level of optimization, resulting in situations where the threads could remain looping forever. Here we use memory barriers between reads to enforce a strict ordering and the asm code produced does exactly what the C code does and works perfectly, with a 3-digit measurement accuracy observed during a test.
2017-10-31 16:54:15 +00:00
curr = ctr->curr_ctr;
REORG: threads: extract atomic ops from hathreads.h The hathreads.h file has quickly become a total mess because it contains thread definitions, atomic operations and locking operations, all this for multiple combinations of threads, debugging and architectures, and all this done with random ordering! This first patch extracts all the atomic ops code from hathreads.h to move it to haproxy/atomic.h. The code there still contains several sections based on non-thread vs thread, and GCC versions in the latter case. Each section was arranged in the exact same order to ease finding. The redundant HA_BARRIER() which was the same as __ha_compiler_barrier() was dropped in favor of the latter which follows the naming convention of all other barriers. It was only used in freq_ctr.c which was updated. Additionally, __ha_compiler_barrier() was defined inconditionally but used only for thread-related operations, so it was made thread-only like HA_BARRIER() used to be. We'd still need to have two types of compiler barriers, one for the general case (e.g. signals) and another one for concurrency, but this was not addressed here. Some comments were added at the beginning of each section to inform about the use case and warn about the traps to avoid. Some files which continue to include hathreads.h solely for atomic ops should now be updated.
2020-05-28 13:29:33 +00:00
__ha_compiler_barrier();
BUG/MAJOR: threads/freq_ctr: use a memory barrier to detect changes commit 6e01286 (BUG/MAJOR: threads/freq_ctr: fix lock on freq counters) attempted to fix the loop using volatile but that doesn't work depending on the level of optimization, resulting in situations where the threads could remain looping forever. Here we use memory barriers between reads to enforce a strict ordering and the asm code produced does exactly what the C code does and works perfectly, with a 3-digit measurement accuracy observed during a test.
2017-10-31 16:54:15 +00:00
past = ctr->prev_ctr;
REORG: threads: extract atomic ops from hathreads.h The hathreads.h file has quickly become a total mess because it contains thread definitions, atomic operations and locking operations, all this for multiple combinations of threads, debugging and architectures, and all this done with random ordering! This first patch extracts all the atomic ops code from hathreads.h to move it to haproxy/atomic.h. The code there still contains several sections based on non-thread vs thread, and GCC versions in the latter case. Each section was arranged in the exact same order to ease finding. The redundant HA_BARRIER() which was the same as __ha_compiler_barrier() was dropped in favor of the latter which follows the naming convention of all other barriers. It was only used in freq_ctr.c which was updated. Additionally, __ha_compiler_barrier() was defined inconditionally but used only for thread-related operations, so it was made thread-only like HA_BARRIER() used to be. We'd still need to have two types of compiler barriers, one for the general case (e.g. signals) and another one for concurrency, but this was not addressed here. Some comments were added at the beginning of each section to inform about the use case and warn about the traps to avoid. Some files which continue to include hathreads.h solely for atomic ops should now be updated.
2020-05-28 13:29:33 +00:00
__ha_compiler_barrier();
BUG/MAJOR: threads/freq_ctr: use a memory barrier to detect changes commit 6e01286 (BUG/MAJOR: threads/freq_ctr: fix lock on freq counters) attempted to fix the loop using volatile but that doesn't work depending on the level of optimization, resulting in situations where the threads could remain looping forever. Here we use memory barriers between reads to enforce a strict ordering and the asm code produced does exactly what the C code does and works perfectly, with a 3-digit measurement accuracy observed during a test.
2017-10-31 16:54:15 +00:00
curr_sec = ctr->curr_sec;
REORG: threads: extract atomic ops from hathreads.h The hathreads.h file has quickly become a total mess because it contains thread definitions, atomic operations and locking operations, all this for multiple combinations of threads, debugging and architectures, and all this done with random ordering! This first patch extracts all the atomic ops code from hathreads.h to move it to haproxy/atomic.h. The code there still contains several sections based on non-thread vs thread, and GCC versions in the latter case. Each section was arranged in the exact same order to ease finding. The redundant HA_BARRIER() which was the same as __ha_compiler_barrier() was dropped in favor of the latter which follows the naming convention of all other barriers. It was only used in freq_ctr.c which was updated. Additionally, __ha_compiler_barrier() was defined inconditionally but used only for thread-related operations, so it was made thread-only like HA_BARRIER() used to be. We'd still need to have two types of compiler barriers, one for the general case (e.g. signals) and another one for concurrency, but this was not addressed here. Some comments were added at the beginning of each section to inform about the use case and warn about the traps to avoid. Some files which continue to include hathreads.h solely for atomic ops should now be updated.
2020-05-28 13:29:33 +00:00
__ha_compiler_barrier();
BUG/MAJOR: threads/freq_ctr: fix lock on freq counters. The wrong bit was set to keep the lock on freq counter update. And the read functions were re-worked to use volatile. Moreover, when a freq counter is updated, it is now rotated only if the current counter is in the past (now.tv_sec > ctr->curr_sec). It is important with threads because the current time (now) is thread-local. So, rounded to the second, the time may vary by more or less 1 second. So a freq counter rotated by one thread may be see 1 second in the future. In this case, it is updated but not rotated.
2017-10-30 17:04:28 +00:00
if (_curr == curr && _past == past && _curr_sec == curr_sec)
break;
}
[OPTIM] rate-limit: cleaner behaviour on low rates and reduce consumption The rate-limit was applied to the smoothed value which does a special case for frequencies below 2 events per period. This caused irregular limitations when set to 1 session per second. The proper way to handle this is to compute the number of remaining events that can occur without reaching the limit. This is what has been added. It also has the benefit that the frequency calculation is now done once when entering event_accept(), before the accept() loop, and not once per accept() loop anymore, thus saving a few CPU cycles during very high loads. With this fix, rate limits of 1/s are perfectly respected.
2009-03-06 08:18:27 +00:00
MEDIUM: threads/freq_ctr: Make the frequency counters thread-safe When a frequency counter must be updated, we use the curr_sec/curr_tick fields as a lock, by setting the MSB to 1 in a compare-and-swap to lock and by reseting it to unlock. And when we need to read it, we loop until the counter is unlocked. This way, the frequency counters are thread-safe without any external lock. It is important to avoid increasing the size of many structures (global, proxy, server, stick_table).
2017-10-12 07:49:09 +00:00
age = now.tv_sec - curr_sec;
if (unlikely(age > 1))
curr = 0;
else {
if (unlikely(age == 1)) {
past = curr;
curr = 0;
[OPTIM] freq_ctr: do not rotate the counters when reading It's easier to take the counter's age into account when consulting it than to rotate it first. It also saves some CPU cycles and avoids the multiply for outdated counters, finally saving CPU cycles here too when multiple operations need to read the same counter. The freq_ctr code has also shrinked by one third consecutively to these optimizations.
2009-03-06 13:29:25 +00:00
}
BUG/MINOR: time: frequency counters are not totally accurate When a frontend is rate-limited to 1000 connections per second, the effective rate measured from the client is 999/s, and connections experience an average response time of 99.5 ms with a standard deviation of 2 ms. The reason for this inaccuracy is that when computing frequency counters, we use one part of the previous value proportional to the number of milliseconds remaining in the current second. But even the last millisecond still uses a part of the past value, which is wrong : since we have a 1ms resolution, the last millisecond must be dedicated only to filling the current second. So we slightly adjust the algorithm to use 999/1000 of the past value during the first millisecond, and 0/1000 of the past value during the last millisecond. We also slightly improve the computation by computing the remaining time instead of the current time in tv_update_date(), so that we don't have to negate the value in each frequency counter. Now with the fix, the connection rate measured by both the client and haproxy is a steady 1000/s, the average response time measured is 99.2ms and more importantly, the standard deviation has been divided by 3 to 0.6 millisecond. This fix should also be backported to 1.4 which has the same issue.
2012-12-29 20:50:07 +00:00
curr += mul32hi(past, ms_left_scaled);
[OPTIM] freq_ctr: do not rotate the counters when reading It's easier to take the counter's age into account when consulting it than to rotate it first. It also saves some CPU cycles and avoids the multiply for outdated counters, finally saving CPU cycles here too when multiple operations need to read the same counter. The freq_ctr code has also shrinked by one third consecutively to these optimizations.
2009-03-06 13:29:25 +00:00
}
curr += pend;
[OPTIM] rate-limit: cleaner behaviour on low rates and reduce consumption The rate-limit was applied to the smoothed value which does a special case for frequencies below 2 events per period. This caused irregular limitations when set to 1 session per second. The proper way to handle this is to compute the number of remaining events that can occur without reaching the limit. This is what has been added. It also has the benefit that the frequency calculation is now done once when entering event_accept(), before the accept() loop, and not once per accept() loop anymore, thus saving a few CPU cycles during very high loads. With this fix, rate limits of 1/s are perfectly respected.
2009-03-06 08:18:27 +00:00
[OPTIM] freq_ctr: do not rotate the counters when reading It's easier to take the counter's age into account when consulting it than to rotate it first. It also saves some CPU cycles and avoids the multiply for outdated counters, finally saving CPU cycles here too when multiple operations need to read the same counter. The freq_ctr code has also shrinked by one third consecutively to these optimizations.
2009-03-06 13:29:25 +00:00
if (curr >= freq)
[OPTIM] rate-limit: cleaner behaviour on low rates and reduce consumption The rate-limit was applied to the smoothed value which does a special case for frequencies below 2 events per period. This caused irregular limitations when set to 1 session per second. The proper way to handle this is to compute the number of remaining events that can occur without reaching the limit. This is what has been added. It also has the benefit that the frequency calculation is now done once when entering event_accept(), before the accept() loop, and not once per accept() loop anymore, thus saving a few CPU cycles during very high loads. With this fix, rate limits of 1/s are perfectly respected.
2009-03-06 08:18:27 +00:00
return 0;
[OPTIM] freq_ctr: do not rotate the counters when reading It's easier to take the counter's age into account when consulting it than to rotate it first. It also saves some CPU cycles and avoids the multiply for outdated counters, finally saving CPU cycles here too when multiple operations need to read the same counter. The freq_ctr code has also shrinked by one third consecutively to these optimizations.
2009-03-06 13:29:25 +00:00
return freq - curr;
[OPTIM] rate-limit: cleaner behaviour on low rates and reduce consumption The rate-limit was applied to the smoothed value which does a special case for frequencies below 2 events per period. This caused irregular limitations when set to 1 session per second. The proper way to handle this is to compute the number of remaining events that can occur without reaching the limit. This is what has been added. It also has the benefit that the frequency calculation is now done once when entering event_accept(), before the accept() loop, and not once per accept() loop anymore, thus saving a few CPU cycles during very high loads. With this fix, rate limits of 1/s are perfectly respected.
2009-03-06 08:18:27 +00:00
}
/* return the expected wait time in ms before the next event may occur,
* respecting frequency <freq>, and assuming there may already be some pending
* events. It returns zero if we can proceed immediately, otherwise the wait
* time, which will be rounded down 1ms for better accuracy, with a minimum
* of one ms.
*/
unsigned int next_event_delay(struct freq_ctr *ctr, unsigned int freq, unsigned int pend)
{
BUG/MAJOR: threads/freq_ctr: fix lock on freq counters. The wrong bit was set to keep the lock on freq counter update. And the read functions were re-worked to use volatile. Moreover, when a freq counter is updated, it is now rotated only if the current counter is in the past (now.tv_sec > ctr->curr_sec). It is important with threads because the current time (now) is thread-local. So, rounded to the second, the time may vary by more or less 1 second. So a freq counter rotated by one thread may be see 1 second in the future. In this case, it is updated but not rotated.
2017-10-30 17:04:28 +00:00
unsigned int curr, past, _curr, _past;
unsigned int wait, age, curr_sec, _curr_sec;
BUG/MAJOR: threads/freq_ctr: use a memory barrier to detect changes commit 6e01286 (BUG/MAJOR: threads/freq_ctr: fix lock on freq counters) attempted to fix the loop using volatile but that doesn't work depending on the level of optimization, resulting in situations where the threads could remain looping forever. Here we use memory barriers between reads to enforce a strict ordering and the asm code produced does exactly what the C code does and works perfectly, with a 3-digit measurement accuracy observed during a test.
2017-10-31 16:54:15 +00:00
while (1) {
_curr = ctr->curr_ctr;
REORG: threads: extract atomic ops from hathreads.h The hathreads.h file has quickly become a total mess because it contains thread definitions, atomic operations and locking operations, all this for multiple combinations of threads, debugging and architectures, and all this done with random ordering! This first patch extracts all the atomic ops code from hathreads.h to move it to haproxy/atomic.h. The code there still contains several sections based on non-thread vs thread, and GCC versions in the latter case. Each section was arranged in the exact same order to ease finding. The redundant HA_BARRIER() which was the same as __ha_compiler_barrier() was dropped in favor of the latter which follows the naming convention of all other barriers. It was only used in freq_ctr.c which was updated. Additionally, __ha_compiler_barrier() was defined inconditionally but used only for thread-related operations, so it was made thread-only like HA_BARRIER() used to be. We'd still need to have two types of compiler barriers, one for the general case (e.g. signals) and another one for concurrency, but this was not addressed here. Some comments were added at the beginning of each section to inform about the use case and warn about the traps to avoid. Some files which continue to include hathreads.h solely for atomic ops should now be updated.
2020-05-28 13:29:33 +00:00
__ha_compiler_barrier();
BUG/MAJOR: threads/freq_ctr: use a memory barrier to detect changes commit 6e01286 (BUG/MAJOR: threads/freq_ctr: fix lock on freq counters) attempted to fix the loop using volatile but that doesn't work depending on the level of optimization, resulting in situations where the threads could remain looping forever. Here we use memory barriers between reads to enforce a strict ordering and the asm code produced does exactly what the C code does and works perfectly, with a 3-digit measurement accuracy observed during a test.
2017-10-31 16:54:15 +00:00
_past = ctr->prev_ctr;
REORG: threads: extract atomic ops from hathreads.h The hathreads.h file has quickly become a total mess because it contains thread definitions, atomic operations and locking operations, all this for multiple combinations of threads, debugging and architectures, and all this done with random ordering! This first patch extracts all the atomic ops code from hathreads.h to move it to haproxy/atomic.h. The code there still contains several sections based on non-thread vs thread, and GCC versions in the latter case. Each section was arranged in the exact same order to ease finding. The redundant HA_BARRIER() which was the same as __ha_compiler_barrier() was dropped in favor of the latter which follows the naming convention of all other barriers. It was only used in freq_ctr.c which was updated. Additionally, __ha_compiler_barrier() was defined inconditionally but used only for thread-related operations, so it was made thread-only like HA_BARRIER() used to be. We'd still need to have two types of compiler barriers, one for the general case (e.g. signals) and another one for concurrency, but this was not addressed here. Some comments were added at the beginning of each section to inform about the use case and warn about the traps to avoid. Some files which continue to include hathreads.h solely for atomic ops should now be updated.
2020-05-28 13:29:33 +00:00
__ha_compiler_barrier();
BUG/MAJOR: threads/freq_ctr: use a memory barrier to detect changes commit 6e01286 (BUG/MAJOR: threads/freq_ctr: fix lock on freq counters) attempted to fix the loop using volatile but that doesn't work depending on the level of optimization, resulting in situations where the threads could remain looping forever. Here we use memory barriers between reads to enforce a strict ordering and the asm code produced does exactly what the C code does and works perfectly, with a 3-digit measurement accuracy observed during a test.
2017-10-31 16:54:15 +00:00
_curr_sec = ctr->curr_sec;
REORG: threads: extract atomic ops from hathreads.h The hathreads.h file has quickly become a total mess because it contains thread definitions, atomic operations and locking operations, all this for multiple combinations of threads, debugging and architectures, and all this done with random ordering! This first patch extracts all the atomic ops code from hathreads.h to move it to haproxy/atomic.h. The code there still contains several sections based on non-thread vs thread, and GCC versions in the latter case. Each section was arranged in the exact same order to ease finding. The redundant HA_BARRIER() which was the same as __ha_compiler_barrier() was dropped in favor of the latter which follows the naming convention of all other barriers. It was only used in freq_ctr.c which was updated. Additionally, __ha_compiler_barrier() was defined inconditionally but used only for thread-related operations, so it was made thread-only like HA_BARRIER() used to be. We'd still need to have two types of compiler barriers, one for the general case (e.g. signals) and another one for concurrency, but this was not addressed here. Some comments were added at the beginning of each section to inform about the use case and warn about the traps to avoid. Some files which continue to include hathreads.h solely for atomic ops should now be updated.
2020-05-28 13:29:33 +00:00
__ha_compiler_barrier();
BUG/MAJOR: threads/freq_ctr: fix lock on freq counters. The wrong bit was set to keep the lock on freq counter update. And the read functions were re-worked to use volatile. Moreover, when a freq counter is updated, it is now rotated only if the current counter is in the past (now.tv_sec > ctr->curr_sec). It is important with threads because the current time (now) is thread-local. So, rounded to the second, the time may vary by more or less 1 second. So a freq counter rotated by one thread may be see 1 second in the future. In this case, it is updated but not rotated.
2017-10-30 17:04:28 +00:00
if (_curr_sec & 0x80000000)
continue;
BUG/MAJOR: threads/freq_ctr: use a memory barrier to detect changes commit 6e01286 (BUG/MAJOR: threads/freq_ctr: fix lock on freq counters) attempted to fix the loop using volatile but that doesn't work depending on the level of optimization, resulting in situations where the threads could remain looping forever. Here we use memory barriers between reads to enforce a strict ordering and the asm code produced does exactly what the C code does and works perfectly, with a 3-digit measurement accuracy observed during a test.
2017-10-31 16:54:15 +00:00
curr = ctr->curr_ctr;
REORG: threads: extract atomic ops from hathreads.h The hathreads.h file has quickly become a total mess because it contains thread definitions, atomic operations and locking operations, all this for multiple combinations of threads, debugging and architectures, and all this done with random ordering! This first patch extracts all the atomic ops code from hathreads.h to move it to haproxy/atomic.h. The code there still contains several sections based on non-thread vs thread, and GCC versions in the latter case. Each section was arranged in the exact same order to ease finding. The redundant HA_BARRIER() which was the same as __ha_compiler_barrier() was dropped in favor of the latter which follows the naming convention of all other barriers. It was only used in freq_ctr.c which was updated. Additionally, __ha_compiler_barrier() was defined inconditionally but used only for thread-related operations, so it was made thread-only like HA_BARRIER() used to be. We'd still need to have two types of compiler barriers, one for the general case (e.g. signals) and another one for concurrency, but this was not addressed here. Some comments were added at the beginning of each section to inform about the use case and warn about the traps to avoid. Some files which continue to include hathreads.h solely for atomic ops should now be updated.
2020-05-28 13:29:33 +00:00
__ha_compiler_barrier();
BUG/MAJOR: threads/freq_ctr: use a memory barrier to detect changes commit 6e01286 (BUG/MAJOR: threads/freq_ctr: fix lock on freq counters) attempted to fix the loop using volatile but that doesn't work depending on the level of optimization, resulting in situations where the threads could remain looping forever. Here we use memory barriers between reads to enforce a strict ordering and the asm code produced does exactly what the C code does and works perfectly, with a 3-digit measurement accuracy observed during a test.
2017-10-31 16:54:15 +00:00
past = ctr->prev_ctr;
REORG: threads: extract atomic ops from hathreads.h The hathreads.h file has quickly become a total mess because it contains thread definitions, atomic operations and locking operations, all this for multiple combinations of threads, debugging and architectures, and all this done with random ordering! This first patch extracts all the atomic ops code from hathreads.h to move it to haproxy/atomic.h. The code there still contains several sections based on non-thread vs thread, and GCC versions in the latter case. Each section was arranged in the exact same order to ease finding. The redundant HA_BARRIER() which was the same as __ha_compiler_barrier() was dropped in favor of the latter which follows the naming convention of all other barriers. It was only used in freq_ctr.c which was updated. Additionally, __ha_compiler_barrier() was defined inconditionally but used only for thread-related operations, so it was made thread-only like HA_BARRIER() used to be. We'd still need to have two types of compiler barriers, one for the general case (e.g. signals) and another one for concurrency, but this was not addressed here. Some comments were added at the beginning of each section to inform about the use case and warn about the traps to avoid. Some files which continue to include hathreads.h solely for atomic ops should now be updated.
2020-05-28 13:29:33 +00:00
__ha_compiler_barrier();
BUG/MAJOR: threads/freq_ctr: use a memory barrier to detect changes commit 6e01286 (BUG/MAJOR: threads/freq_ctr: fix lock on freq counters) attempted to fix the loop using volatile but that doesn't work depending on the level of optimization, resulting in situations where the threads could remain looping forever. Here we use memory barriers between reads to enforce a strict ordering and the asm code produced does exactly what the C code does and works perfectly, with a 3-digit measurement accuracy observed during a test.
2017-10-31 16:54:15 +00:00
curr_sec = ctr->curr_sec;
REORG: threads: extract atomic ops from hathreads.h The hathreads.h file has quickly become a total mess because it contains thread definitions, atomic operations and locking operations, all this for multiple combinations of threads, debugging and architectures, and all this done with random ordering! This first patch extracts all the atomic ops code from hathreads.h to move it to haproxy/atomic.h. The code there still contains several sections based on non-thread vs thread, and GCC versions in the latter case. Each section was arranged in the exact same order to ease finding. The redundant HA_BARRIER() which was the same as __ha_compiler_barrier() was dropped in favor of the latter which follows the naming convention of all other barriers. It was only used in freq_ctr.c which was updated. Additionally, __ha_compiler_barrier() was defined inconditionally but used only for thread-related operations, so it was made thread-only like HA_BARRIER() used to be. We'd still need to have two types of compiler barriers, one for the general case (e.g. signals) and another one for concurrency, but this was not addressed here. Some comments were added at the beginning of each section to inform about the use case and warn about the traps to avoid. Some files which continue to include hathreads.h solely for atomic ops should now be updated.
2020-05-28 13:29:33 +00:00
__ha_compiler_barrier();
BUG/MAJOR: threads/freq_ctr: fix lock on freq counters. The wrong bit was set to keep the lock on freq counter update. And the read functions were re-worked to use volatile. Moreover, when a freq counter is updated, it is now rotated only if the current counter is in the past (now.tv_sec > ctr->curr_sec). It is important with threads because the current time (now) is thread-local. So, rounded to the second, the time may vary by more or less 1 second. So a freq counter rotated by one thread may be see 1 second in the future. In this case, it is updated but not rotated.
2017-10-30 17:04:28 +00:00
if (_curr == curr && _past == past && _curr_sec == curr_sec)
break;
}
[OPTIM] rate-limit: cleaner behaviour on low rates and reduce consumption The rate-limit was applied to the smoothed value which does a special case for frequencies below 2 events per period. This caused irregular limitations when set to 1 session per second. The proper way to handle this is to compute the number of remaining events that can occur without reaching the limit. This is what has been added. It also has the benefit that the frequency calculation is now done once when entering event_accept(), before the accept() loop, and not once per accept() loop anymore, thus saving a few CPU cycles during very high loads. With this fix, rate limits of 1/s are perfectly respected.
2009-03-06 08:18:27 +00:00
MEDIUM: threads/freq_ctr: Make the frequency counters thread-safe When a frequency counter must be updated, we use the curr_sec/curr_tick fields as a lock, by setting the MSB to 1 in a compare-and-swap to lock and by reseting it to unlock. And when we need to read it, we loop until the counter is unlocked. This way, the frequency counters are thread-safe without any external lock. It is important to avoid increasing the size of many structures (global, proxy, server, stick_table).
2017-10-12 07:49:09 +00:00
age = now.tv_sec - curr_sec;
if (unlikely(age > 1))
curr = 0;
else {
if (unlikely(age == 1)) {
past = curr;
curr = 0;
[OPTIM] freq_ctr: do not rotate the counters when reading It's easier to take the counter's age into account when consulting it than to rotate it first. It also saves some CPU cycles and avoids the multiply for outdated counters, finally saving CPU cycles here too when multiple operations need to read the same counter. The freq_ctr code has also shrinked by one third consecutively to these optimizations.
2009-03-06 13:29:25 +00:00
}
BUG/MINOR: time: frequency counters are not totally accurate When a frontend is rate-limited to 1000 connections per second, the effective rate measured from the client is 999/s, and connections experience an average response time of 99.5 ms with a standard deviation of 2 ms. The reason for this inaccuracy is that when computing frequency counters, we use one part of the previous value proportional to the number of milliseconds remaining in the current second. But even the last millisecond still uses a part of the past value, which is wrong : since we have a 1ms resolution, the last millisecond must be dedicated only to filling the current second. So we slightly adjust the algorithm to use 999/1000 of the past value during the first millisecond, and 0/1000 of the past value during the last millisecond. We also slightly improve the computation by computing the remaining time instead of the current time in tv_update_date(), so that we don't have to negate the value in each frequency counter. Now with the fix, the connection rate measured by both the client and haproxy is a steady 1000/s, the average response time measured is 99.2ms and more importantly, the standard deviation has been divided by 3 to 0.6 millisecond. This fix should also be backported to 1.4 which has the same issue.
2012-12-29 20:50:07 +00:00
curr += mul32hi(past, ms_left_scaled);
[OPTIM] freq_ctr: do not rotate the counters when reading It's easier to take the counter's age into account when consulting it than to rotate it first. It also saves some CPU cycles and avoids the multiply for outdated counters, finally saving CPU cycles here too when multiple operations need to read the same counter. The freq_ctr code has also shrinked by one third consecutively to these optimizations.
2009-03-06 13:29:25 +00:00
}
curr += pend;
[OPTIM] rate-limit: cleaner behaviour on low rates and reduce consumption The rate-limit was applied to the smoothed value which does a special case for frequencies below 2 events per period. This caused irregular limitations when set to 1 session per second. The proper way to handle this is to compute the number of remaining events that can occur without reaching the limit. This is what has been added. It also has the benefit that the frequency calculation is now done once when entering event_accept(), before the accept() loop, and not once per accept() loop anymore, thus saving a few CPU cycles during very high loads. With this fix, rate limits of 1/s are perfectly respected.
2009-03-06 08:18:27 +00:00
[OPTIM] freq_ctr: do not rotate the counters when reading It's easier to take the counter's age into account when consulting it than to rotate it first. It also saves some CPU cycles and avoids the multiply for outdated counters, finally saving CPU cycles here too when multiple operations need to read the same counter. The freq_ctr code has also shrinked by one third consecutively to these optimizations.
2009-03-06 13:29:25 +00:00
if (curr < freq)
[OPTIM] rate-limit: cleaner behaviour on low rates and reduce consumption The rate-limit was applied to the smoothed value which does a special case for frequencies below 2 events per period. This caused irregular limitations when set to 1 session per second. The proper way to handle this is to compute the number of remaining events that can occur without reaching the limit. This is what has been added. It also has the benefit that the frequency calculation is now done once when entering event_accept(), before the accept() loop, and not once per accept() loop anymore, thus saving a few CPU cycles during very high loads. With this fix, rate limits of 1/s are perfectly respected.
2009-03-06 08:18:27 +00:00
return 0;
[OPTIM] freq_ctr: do not rotate the counters when reading It's easier to take the counter's age into account when consulting it than to rotate it first. It also saves some CPU cycles and avoids the multiply for outdated counters, finally saving CPU cycles here too when multiple operations need to read the same counter. The freq_ctr code has also shrinked by one third consecutively to these optimizations.
2009-03-06 13:29:25 +00:00
wait = 999 / curr;
[OPTIM] rate-limit: cleaner behaviour on low rates and reduce consumption The rate-limit was applied to the smoothed value which does a special case for frequencies below 2 events per period. This caused irregular limitations when set to 1 session per second. The proper way to handle this is to compute the number of remaining events that can occur without reaching the limit. This is what has been added. It also has the benefit that the frequency calculation is now done once when entering event_accept(), before the accept() loop, and not once per accept() loop anymore, thus saving a few CPU cycles during very high loads. With this fix, rate limits of 1/s are perfectly respected.
2009-03-06 08:18:27 +00:00
return MAX(wait, 1);
}
[MINOR] freq_ctr: add new types and functions for periods different from 1s Some freq counters will have to work on periods different from 1 second. The original freq counters rely on the period to be exactly one second. The new ones (freq_ctr_period) let the user define the period in ticks, and all computations are operated over that period. When reading a value, it indicates the amount of events over that period too.
2010-06-20 05:15:43 +00:00
/* Reads a frequency counter taking history into account for missing time in
* current period. The period has to be passed in number of ticks and must
* match the one used to feed the counter. The counter value is reported for
* current date (now_ms). The return value has the same precision as one input
* data sample, so low rates over the period will be inaccurate but still
* appropriate for max checking. One trick we use for low values is to specially
* handle the case where the rate is between 0 and 1 in order to avoid flapping
* while waiting for the next event.
*
* For immediate limit checking, it's recommended to use freq_ctr_period_remain()
* instead which does not have the flapping correction, so that even frequencies
* as low as one event/period are properly handled.
*
* For measures over a 1-second period, it's better to use the implicit functions
* above.
*/
unsigned int read_freq_ctr_period(struct freq_ctr_period *ctr, unsigned int period)
{
BUG/MAJOR: threads/freq_ctr: fix lock on freq counters. The wrong bit was set to keep the lock on freq counter update. And the read functions were re-worked to use volatile. Moreover, when a freq counter is updated, it is now rotated only if the current counter is in the past (now.tv_sec > ctr->curr_sec). It is important with threads because the current time (now) is thread-local. So, rounded to the second, the time may vary by more or less 1 second. So a freq counter rotated by one thread may be see 1 second in the future. In this case, it is updated but not rotated.
2017-10-30 17:04:28 +00:00
unsigned int _curr, _past, curr, past;
unsigned int remain, _curr_tick, curr_tick;
BUG/MAJOR: threads/freq_ctr: use a memory barrier to detect changes commit 6e01286 (BUG/MAJOR: threads/freq_ctr: fix lock on freq counters) attempted to fix the loop using volatile but that doesn't work depending on the level of optimization, resulting in situations where the threads could remain looping forever. Here we use memory barriers between reads to enforce a strict ordering and the asm code produced does exactly what the C code does and works perfectly, with a 3-digit measurement accuracy observed during a test.
2017-10-31 16:54:15 +00:00
while (1) {
BUG/MAJOR: threads/freq_ctr: fix lock on freq counters. The wrong bit was set to keep the lock on freq counter update. And the read functions were re-worked to use volatile. Moreover, when a freq counter is updated, it is now rotated only if the current counter is in the past (now.tv_sec > ctr->curr_sec). It is important with threads because the current time (now) is thread-local. So, rounded to the second, the time may vary by more or less 1 second. So a freq counter rotated by one thread may be see 1 second in the future. In this case, it is updated but not rotated.
2017-10-30 17:04:28 +00:00
_curr = ctr->curr_ctr;
REORG: threads: extract atomic ops from hathreads.h The hathreads.h file has quickly become a total mess because it contains thread definitions, atomic operations and locking operations, all this for multiple combinations of threads, debugging and architectures, and all this done with random ordering! This first patch extracts all the atomic ops code from hathreads.h to move it to haproxy/atomic.h. The code there still contains several sections based on non-thread vs thread, and GCC versions in the latter case. Each section was arranged in the exact same order to ease finding. The redundant HA_BARRIER() which was the same as __ha_compiler_barrier() was dropped in favor of the latter which follows the naming convention of all other barriers. It was only used in freq_ctr.c which was updated. Additionally, __ha_compiler_barrier() was defined inconditionally but used only for thread-related operations, so it was made thread-only like HA_BARRIER() used to be. We'd still need to have two types of compiler barriers, one for the general case (e.g. signals) and another one for concurrency, but this was not addressed here. Some comments were added at the beginning of each section to inform about the use case and warn about the traps to avoid. Some files which continue to include hathreads.h solely for atomic ops should now be updated.
2020-05-28 13:29:33 +00:00
__ha_compiler_barrier();
BUG/MAJOR: threads/freq_ctr: fix lock on freq counters. The wrong bit was set to keep the lock on freq counter update. And the read functions were re-worked to use volatile. Moreover, when a freq counter is updated, it is now rotated only if the current counter is in the past (now.tv_sec > ctr->curr_sec). It is important with threads because the current time (now) is thread-local. So, rounded to the second, the time may vary by more or less 1 second. So a freq counter rotated by one thread may be see 1 second in the future. In this case, it is updated but not rotated.
2017-10-30 17:04:28 +00:00
_past = ctr->prev_ctr;
REORG: threads: extract atomic ops from hathreads.h The hathreads.h file has quickly become a total mess because it contains thread definitions, atomic operations and locking operations, all this for multiple combinations of threads, debugging and architectures, and all this done with random ordering! This first patch extracts all the atomic ops code from hathreads.h to move it to haproxy/atomic.h. The code there still contains several sections based on non-thread vs thread, and GCC versions in the latter case. Each section was arranged in the exact same order to ease finding. The redundant HA_BARRIER() which was the same as __ha_compiler_barrier() was dropped in favor of the latter which follows the naming convention of all other barriers. It was only used in freq_ctr.c which was updated. Additionally, __ha_compiler_barrier() was defined inconditionally but used only for thread-related operations, so it was made thread-only like HA_BARRIER() used to be. We'd still need to have two types of compiler barriers, one for the general case (e.g. signals) and another one for concurrency, but this was not addressed here. Some comments were added at the beginning of each section to inform about the use case and warn about the traps to avoid. Some files which continue to include hathreads.h solely for atomic ops should now be updated.
2020-05-28 13:29:33 +00:00
__ha_compiler_barrier();
BUG/MAJOR: threads/freq_ctr: fix lock on freq counters. The wrong bit was set to keep the lock on freq counter update. And the read functions were re-worked to use volatile. Moreover, when a freq counter is updated, it is now rotated only if the current counter is in the past (now.tv_sec > ctr->curr_sec). It is important with threads because the current time (now) is thread-local. So, rounded to the second, the time may vary by more or less 1 second. So a freq counter rotated by one thread may be see 1 second in the future. In this case, it is updated but not rotated.
2017-10-30 17:04:28 +00:00
_curr_tick = ctr->curr_tick;
REORG: threads: extract atomic ops from hathreads.h The hathreads.h file has quickly become a total mess because it contains thread definitions, atomic operations and locking operations, all this for multiple combinations of threads, debugging and architectures, and all this done with random ordering! This first patch extracts all the atomic ops code from hathreads.h to move it to haproxy/atomic.h. The code there still contains several sections based on non-thread vs thread, and GCC versions in the latter case. Each section was arranged in the exact same order to ease finding. The redundant HA_BARRIER() which was the same as __ha_compiler_barrier() was dropped in favor of the latter which follows the naming convention of all other barriers. It was only used in freq_ctr.c which was updated. Additionally, __ha_compiler_barrier() was defined inconditionally but used only for thread-related operations, so it was made thread-only like HA_BARRIER() used to be. We'd still need to have two types of compiler barriers, one for the general case (e.g. signals) and another one for concurrency, but this was not addressed here. Some comments were added at the beginning of each section to inform about the use case and warn about the traps to avoid. Some files which continue to include hathreads.h solely for atomic ops should now be updated.
2020-05-28 13:29:33 +00:00
__ha_compiler_barrier();
BUG/MAJOR: threads/freq_ctr: fix lock on freq counters. The wrong bit was set to keep the lock on freq counter update. And the read functions were re-worked to use volatile. Moreover, when a freq counter is updated, it is now rotated only if the current counter is in the past (now.tv_sec > ctr->curr_sec). It is important with threads because the current time (now) is thread-local. So, rounded to the second, the time may vary by more or less 1 second. So a freq counter rotated by one thread may be see 1 second in the future. In this case, it is updated but not rotated.
2017-10-30 17:04:28 +00:00
if (_curr_tick & 0x1)
continue;
MEDIUM: threads/freq_ctr: Make the frequency counters thread-safe When a frequency counter must be updated, we use the curr_sec/curr_tick fields as a lock, by setting the MSB to 1 in a compare-and-swap to lock and by reseting it to unlock. And when we need to read it, we loop until the counter is unlocked. This way, the frequency counters are thread-safe without any external lock. It is important to avoid increasing the size of many structures (global, proxy, server, stick_table).
2017-10-12 07:49:09 +00:00
curr = ctr->curr_ctr;
REORG: threads: extract atomic ops from hathreads.h The hathreads.h file has quickly become a total mess because it contains thread definitions, atomic operations and locking operations, all this for multiple combinations of threads, debugging and architectures, and all this done with random ordering! This first patch extracts all the atomic ops code from hathreads.h to move it to haproxy/atomic.h. The code there still contains several sections based on non-thread vs thread, and GCC versions in the latter case. Each section was arranged in the exact same order to ease finding. The redundant HA_BARRIER() which was the same as __ha_compiler_barrier() was dropped in favor of the latter which follows the naming convention of all other barriers. It was only used in freq_ctr.c which was updated. Additionally, __ha_compiler_barrier() was defined inconditionally but used only for thread-related operations, so it was made thread-only like HA_BARRIER() used to be. We'd still need to have two types of compiler barriers, one for the general case (e.g. signals) and another one for concurrency, but this was not addressed here. Some comments were added at the beginning of each section to inform about the use case and warn about the traps to avoid. Some files which continue to include hathreads.h solely for atomic ops should now be updated.
2020-05-28 13:29:33 +00:00
__ha_compiler_barrier();
MEDIUM: threads/freq_ctr: Make the frequency counters thread-safe When a frequency counter must be updated, we use the curr_sec/curr_tick fields as a lock, by setting the MSB to 1 in a compare-and-swap to lock and by reseting it to unlock. And when we need to read it, we loop until the counter is unlocked. This way, the frequency counters are thread-safe without any external lock. It is important to avoid increasing the size of many structures (global, proxy, server, stick_table).
2017-10-12 07:49:09 +00:00
past = ctr->prev_ctr;
REORG: threads: extract atomic ops from hathreads.h The hathreads.h file has quickly become a total mess because it contains thread definitions, atomic operations and locking operations, all this for multiple combinations of threads, debugging and architectures, and all this done with random ordering! This first patch extracts all the atomic ops code from hathreads.h to move it to haproxy/atomic.h. The code there still contains several sections based on non-thread vs thread, and GCC versions in the latter case. Each section was arranged in the exact same order to ease finding. The redundant HA_BARRIER() which was the same as __ha_compiler_barrier() was dropped in favor of the latter which follows the naming convention of all other barriers. It was only used in freq_ctr.c which was updated. Additionally, __ha_compiler_barrier() was defined inconditionally but used only for thread-related operations, so it was made thread-only like HA_BARRIER() used to be. We'd still need to have two types of compiler barriers, one for the general case (e.g. signals) and another one for concurrency, but this was not addressed here. Some comments were added at the beginning of each section to inform about the use case and warn about the traps to avoid. Some files which continue to include hathreads.h solely for atomic ops should now be updated.
2020-05-28 13:29:33 +00:00
__ha_compiler_barrier();
MEDIUM: threads/freq_ctr: Make the frequency counters thread-safe When a frequency counter must be updated, we use the curr_sec/curr_tick fields as a lock, by setting the MSB to 1 in a compare-and-swap to lock and by reseting it to unlock. And when we need to read it, we loop until the counter is unlocked. This way, the frequency counters are thread-safe without any external lock. It is important to avoid increasing the size of many structures (global, proxy, server, stick_table).
2017-10-12 07:49:09 +00:00
curr_tick = ctr->curr_tick;
REORG: threads: extract atomic ops from hathreads.h The hathreads.h file has quickly become a total mess because it contains thread definitions, atomic operations and locking operations, all this for multiple combinations of threads, debugging and architectures, and all this done with random ordering! This first patch extracts all the atomic ops code from hathreads.h to move it to haproxy/atomic.h. The code there still contains several sections based on non-thread vs thread, and GCC versions in the latter case. Each section was arranged in the exact same order to ease finding. The redundant HA_BARRIER() which was the same as __ha_compiler_barrier() was dropped in favor of the latter which follows the naming convention of all other barriers. It was only used in freq_ctr.c which was updated. Additionally, __ha_compiler_barrier() was defined inconditionally but used only for thread-related operations, so it was made thread-only like HA_BARRIER() used to be. We'd still need to have two types of compiler barriers, one for the general case (e.g. signals) and another one for concurrency, but this was not addressed here. Some comments were added at the beginning of each section to inform about the use case and warn about the traps to avoid. Some files which continue to include hathreads.h solely for atomic ops should now be updated.
2020-05-28 13:29:33 +00:00
__ha_compiler_barrier();
BUG/MAJOR: threads/freq_ctr: fix lock on freq counters. The wrong bit was set to keep the lock on freq counter update. And the read functions were re-worked to use volatile. Moreover, when a freq counter is updated, it is now rotated only if the current counter is in the past (now.tv_sec > ctr->curr_sec). It is important with threads because the current time (now) is thread-local. So, rounded to the second, the time may vary by more or less 1 second. So a freq counter rotated by one thread may be see 1 second in the future. In this case, it is updated but not rotated.
2017-10-30 17:04:28 +00:00
if (_curr == curr && _past == past && _curr_tick == curr_tick)
break;
};
[MINOR] freq_ctr: add new types and functions for periods different from 1s Some freq counters will have to work on periods different from 1 second. The original freq counters rely on the period to be exactly one second. The new ones (freq_ctr_period) let the user define the period in ticks, and all computations are operated over that period. When reading a value, it indicates the amount of events over that period too.
2010-06-20 05:15:43 +00:00
MEDIUM: threads/freq_ctr: Make the frequency counters thread-safe When a frequency counter must be updated, we use the curr_sec/curr_tick fields as a lock, by setting the MSB to 1 in a compare-and-swap to lock and by reseting it to unlock. And when we need to read it, we loop until the counter is unlocked. This way, the frequency counters are thread-safe without any external lock. It is important to avoid increasing the size of many structures (global, proxy, server, stick_table).
2017-10-12 07:49:09 +00:00
remain = curr_tick + period - now_ms;
[MINOR] freq_ctr: add new types and functions for periods different from 1s Some freq counters will have to work on periods different from 1 second. The original freq counters rely on the period to be exactly one second. The new ones (freq_ctr_period) let the user define the period in ticks, and all computations are operated over that period. When reading a value, it indicates the amount of events over that period too.
2010-06-20 05:15:43 +00:00
if (unlikely((int)remain < 0)) {
/* We're past the first period, check if we can still report a
* part of last period or if we're too far away.
*/
remain += period;
if ((int)remain < 0)
return 0;
past = curr;
curr = 0;
}
if (past <= 1 && !curr)
return past; /* very low rate, avoid flapping */
curr += div64_32((unsigned long long)past * remain, period);
return curr;
}
/* Returns the number of remaining events that can occur on this freq counter
* while respecting <freq> events per period, and taking into account that
* <pend> events are already known to be pending. Returns 0 if limit was reached.
*/
unsigned int freq_ctr_remain_period(struct freq_ctr_period *ctr, unsigned int period,
unsigned int freq, unsigned int pend)
{
BUG/MAJOR: threads/freq_ctr: fix lock on freq counters. The wrong bit was set to keep the lock on freq counter update. And the read functions were re-worked to use volatile. Moreover, when a freq counter is updated, it is now rotated only if the current counter is in the past (now.tv_sec > ctr->curr_sec). It is important with threads because the current time (now) is thread-local. So, rounded to the second, the time may vary by more or less 1 second. So a freq counter rotated by one thread may be see 1 second in the future. In this case, it is updated but not rotated.
2017-10-30 17:04:28 +00:00
unsigned int _curr, _past, curr, past;
unsigned int remain, _curr_tick, curr_tick;
BUG/MAJOR: threads/freq_ctr: use a memory barrier to detect changes commit 6e01286 (BUG/MAJOR: threads/freq_ctr: fix lock on freq counters) attempted to fix the loop using volatile but that doesn't work depending on the level of optimization, resulting in situations where the threads could remain looping forever. Here we use memory barriers between reads to enforce a strict ordering and the asm code produced does exactly what the C code does and works perfectly, with a 3-digit measurement accuracy observed during a test.
2017-10-31 16:54:15 +00:00
while (1) {
BUG/MAJOR: threads/freq_ctr: fix lock on freq counters. The wrong bit was set to keep the lock on freq counter update. And the read functions were re-worked to use volatile. Moreover, when a freq counter is updated, it is now rotated only if the current counter is in the past (now.tv_sec > ctr->curr_sec). It is important with threads because the current time (now) is thread-local. So, rounded to the second, the time may vary by more or less 1 second. So a freq counter rotated by one thread may be see 1 second in the future. In this case, it is updated but not rotated.
2017-10-30 17:04:28 +00:00
_curr = ctr->curr_ctr;
REORG: threads: extract atomic ops from hathreads.h The hathreads.h file has quickly become a total mess because it contains thread definitions, atomic operations and locking operations, all this for multiple combinations of threads, debugging and architectures, and all this done with random ordering! This first patch extracts all the atomic ops code from hathreads.h to move it to haproxy/atomic.h. The code there still contains several sections based on non-thread vs thread, and GCC versions in the latter case. Each section was arranged in the exact same order to ease finding. The redundant HA_BARRIER() which was the same as __ha_compiler_barrier() was dropped in favor of the latter which follows the naming convention of all other barriers. It was only used in freq_ctr.c which was updated. Additionally, __ha_compiler_barrier() was defined inconditionally but used only for thread-related operations, so it was made thread-only like HA_BARRIER() used to be. We'd still need to have two types of compiler barriers, one for the general case (e.g. signals) and another one for concurrency, but this was not addressed here. Some comments were added at the beginning of each section to inform about the use case and warn about the traps to avoid. Some files which continue to include hathreads.h solely for atomic ops should now be updated.
2020-05-28 13:29:33 +00:00
__ha_compiler_barrier();
BUG/MAJOR: threads/freq_ctr: fix lock on freq counters. The wrong bit was set to keep the lock on freq counter update. And the read functions were re-worked to use volatile. Moreover, when a freq counter is updated, it is now rotated only if the current counter is in the past (now.tv_sec > ctr->curr_sec). It is important with threads because the current time (now) is thread-local. So, rounded to the second, the time may vary by more or less 1 second. So a freq counter rotated by one thread may be see 1 second in the future. In this case, it is updated but not rotated.
2017-10-30 17:04:28 +00:00
_past = ctr->prev_ctr;
REORG: threads: extract atomic ops from hathreads.h The hathreads.h file has quickly become a total mess because it contains thread definitions, atomic operations and locking operations, all this for multiple combinations of threads, debugging and architectures, and all this done with random ordering! This first patch extracts all the atomic ops code from hathreads.h to move it to haproxy/atomic.h. The code there still contains several sections based on non-thread vs thread, and GCC versions in the latter case. Each section was arranged in the exact same order to ease finding. The redundant HA_BARRIER() which was the same as __ha_compiler_barrier() was dropped in favor of the latter which follows the naming convention of all other barriers. It was only used in freq_ctr.c which was updated. Additionally, __ha_compiler_barrier() was defined inconditionally but used only for thread-related operations, so it was made thread-only like HA_BARRIER() used to be. We'd still need to have two types of compiler barriers, one for the general case (e.g. signals) and another one for concurrency, but this was not addressed here. Some comments were added at the beginning of each section to inform about the use case and warn about the traps to avoid. Some files which continue to include hathreads.h solely for atomic ops should now be updated.
2020-05-28 13:29:33 +00:00
__ha_compiler_barrier();
BUG/MAJOR: threads/freq_ctr: fix lock on freq counters. The wrong bit was set to keep the lock on freq counter update. And the read functions were re-worked to use volatile. Moreover, when a freq counter is updated, it is now rotated only if the current counter is in the past (now.tv_sec > ctr->curr_sec). It is important with threads because the current time (now) is thread-local. So, rounded to the second, the time may vary by more or less 1 second. So a freq counter rotated by one thread may be see 1 second in the future. In this case, it is updated but not rotated.
2017-10-30 17:04:28 +00:00
_curr_tick = ctr->curr_tick;
REORG: threads: extract atomic ops from hathreads.h The hathreads.h file has quickly become a total mess because it contains thread definitions, atomic operations and locking operations, all this for multiple combinations of threads, debugging and architectures, and all this done with random ordering! This first patch extracts all the atomic ops code from hathreads.h to move it to haproxy/atomic.h. The code there still contains several sections based on non-thread vs thread, and GCC versions in the latter case. Each section was arranged in the exact same order to ease finding. The redundant HA_BARRIER() which was the same as __ha_compiler_barrier() was dropped in favor of the latter which follows the naming convention of all other barriers. It was only used in freq_ctr.c which was updated. Additionally, __ha_compiler_barrier() was defined inconditionally but used only for thread-related operations, so it was made thread-only like HA_BARRIER() used to be. We'd still need to have two types of compiler barriers, one for the general case (e.g. signals) and another one for concurrency, but this was not addressed here. Some comments were added at the beginning of each section to inform about the use case and warn about the traps to avoid. Some files which continue to include hathreads.h solely for atomic ops should now be updated.
2020-05-28 13:29:33 +00:00
__ha_compiler_barrier();
BUG/MAJOR: threads/freq_ctr: fix lock on freq counters. The wrong bit was set to keep the lock on freq counter update. And the read functions were re-worked to use volatile. Moreover, when a freq counter is updated, it is now rotated only if the current counter is in the past (now.tv_sec > ctr->curr_sec). It is important with threads because the current time (now) is thread-local. So, rounded to the second, the time may vary by more or less 1 second. So a freq counter rotated by one thread may be see 1 second in the future. In this case, it is updated but not rotated.
2017-10-30 17:04:28 +00:00
if (_curr_tick & 0x1)
continue;
MEDIUM: threads/freq_ctr: Make the frequency counters thread-safe When a frequency counter must be updated, we use the curr_sec/curr_tick fields as a lock, by setting the MSB to 1 in a compare-and-swap to lock and by reseting it to unlock. And when we need to read it, we loop until the counter is unlocked. This way, the frequency counters are thread-safe without any external lock. It is important to avoid increasing the size of many structures (global, proxy, server, stick_table).
2017-10-12 07:49:09 +00:00
curr = ctr->curr_ctr;
REORG: threads: extract atomic ops from hathreads.h The hathreads.h file has quickly become a total mess because it contains thread definitions, atomic operations and locking operations, all this for multiple combinations of threads, debugging and architectures, and all this done with random ordering! This first patch extracts all the atomic ops code from hathreads.h to move it to haproxy/atomic.h. The code there still contains several sections based on non-thread vs thread, and GCC versions in the latter case. Each section was arranged in the exact same order to ease finding. The redundant HA_BARRIER() which was the same as __ha_compiler_barrier() was dropped in favor of the latter which follows the naming convention of all other barriers. It was only used in freq_ctr.c which was updated. Additionally, __ha_compiler_barrier() was defined inconditionally but used only for thread-related operations, so it was made thread-only like HA_BARRIER() used to be. We'd still need to have two types of compiler barriers, one for the general case (e.g. signals) and another one for concurrency, but this was not addressed here. Some comments were added at the beginning of each section to inform about the use case and warn about the traps to avoid. Some files which continue to include hathreads.h solely for atomic ops should now be updated.
2020-05-28 13:29:33 +00:00
__ha_compiler_barrier();
MEDIUM: threads/freq_ctr: Make the frequency counters thread-safe When a frequency counter must be updated, we use the curr_sec/curr_tick fields as a lock, by setting the MSB to 1 in a compare-and-swap to lock and by reseting it to unlock. And when we need to read it, we loop until the counter is unlocked. This way, the frequency counters are thread-safe without any external lock. It is important to avoid increasing the size of many structures (global, proxy, server, stick_table).
2017-10-12 07:49:09 +00:00
past = ctr->prev_ctr;
REORG: threads: extract atomic ops from hathreads.h The hathreads.h file has quickly become a total mess because it contains thread definitions, atomic operations and locking operations, all this for multiple combinations of threads, debugging and architectures, and all this done with random ordering! This first patch extracts all the atomic ops code from hathreads.h to move it to haproxy/atomic.h. The code there still contains several sections based on non-thread vs thread, and GCC versions in the latter case. Each section was arranged in the exact same order to ease finding. The redundant HA_BARRIER() which was the same as __ha_compiler_barrier() was dropped in favor of the latter which follows the naming convention of all other barriers. It was only used in freq_ctr.c which was updated. Additionally, __ha_compiler_barrier() was defined inconditionally but used only for thread-related operations, so it was made thread-only like HA_BARRIER() used to be. We'd still need to have two types of compiler barriers, one for the general case (e.g. signals) and another one for concurrency, but this was not addressed here. Some comments were added at the beginning of each section to inform about the use case and warn about the traps to avoid. Some files which continue to include hathreads.h solely for atomic ops should now be updated.
2020-05-28 13:29:33 +00:00
__ha_compiler_barrier();
MEDIUM: threads/freq_ctr: Make the frequency counters thread-safe When a frequency counter must be updated, we use the curr_sec/curr_tick fields as a lock, by setting the MSB to 1 in a compare-and-swap to lock and by reseting it to unlock. And when we need to read it, we loop until the counter is unlocked. This way, the frequency counters are thread-safe without any external lock. It is important to avoid increasing the size of many structures (global, proxy, server, stick_table).
2017-10-12 07:49:09 +00:00
curr_tick = ctr->curr_tick;
REORG: threads: extract atomic ops from hathreads.h The hathreads.h file has quickly become a total mess because it contains thread definitions, atomic operations and locking operations, all this for multiple combinations of threads, debugging and architectures, and all this done with random ordering! This first patch extracts all the atomic ops code from hathreads.h to move it to haproxy/atomic.h. The code there still contains several sections based on non-thread vs thread, and GCC versions in the latter case. Each section was arranged in the exact same order to ease finding. The redundant HA_BARRIER() which was the same as __ha_compiler_barrier() was dropped in favor of the latter which follows the naming convention of all other barriers. It was only used in freq_ctr.c which was updated. Additionally, __ha_compiler_barrier() was defined inconditionally but used only for thread-related operations, so it was made thread-only like HA_BARRIER() used to be. We'd still need to have two types of compiler barriers, one for the general case (e.g. signals) and another one for concurrency, but this was not addressed here. Some comments were added at the beginning of each section to inform about the use case and warn about the traps to avoid. Some files which continue to include hathreads.h solely for atomic ops should now be updated.
2020-05-28 13:29:33 +00:00
__ha_compiler_barrier();
BUG/MAJOR: threads/freq_ctr: fix lock on freq counters. The wrong bit was set to keep the lock on freq counter update. And the read functions were re-worked to use volatile. Moreover, when a freq counter is updated, it is now rotated only if the current counter is in the past (now.tv_sec > ctr->curr_sec). It is important with threads because the current time (now) is thread-local. So, rounded to the second, the time may vary by more or less 1 second. So a freq counter rotated by one thread may be see 1 second in the future. In this case, it is updated but not rotated.
2017-10-30 17:04:28 +00:00
if (_curr == curr && _past == past && _curr_tick == curr_tick)
break;
};
[MINOR] freq_ctr: add new types and functions for periods different from 1s Some freq counters will have to work on periods different from 1 second. The original freq counters rely on the period to be exactly one second. The new ones (freq_ctr_period) let the user define the period in ticks, and all computations are operated over that period. When reading a value, it indicates the amount of events over that period too.
2010-06-20 05:15:43 +00:00
MEDIUM: threads/freq_ctr: Make the frequency counters thread-safe When a frequency counter must be updated, we use the curr_sec/curr_tick fields as a lock, by setting the MSB to 1 in a compare-and-swap to lock and by reseting it to unlock. And when we need to read it, we loop until the counter is unlocked. This way, the frequency counters are thread-safe without any external lock. It is important to avoid increasing the size of many structures (global, proxy, server, stick_table).
2017-10-12 07:49:09 +00:00
remain = curr_tick + period - now_ms;
[MINOR] freq_ctr: add new types and functions for periods different from 1s Some freq counters will have to work on periods different from 1 second. The original freq counters rely on the period to be exactly one second. The new ones (freq_ctr_period) let the user define the period in ticks, and all computations are operated over that period. When reading a value, it indicates the amount of events over that period too.
2010-06-20 05:15:43 +00:00
if (likely((int)remain < 0)) {
/* We're past the first period, check if we can still report a
* part of last period or if we're too far away.
*/
past = curr;
curr = 0;
remain += period;
if ((int)remain < 0)
past = 0;
}
if (likely(past))
curr += div64_32((unsigned long long)past * remain, period);
curr += pend;
freq -= curr;
if ((int)freq < 0)
freq = 0;
return freq;
}
[MEDIUM] measure and report session rate on frontend, backends and servers With this change, all frontends, backends, and servers maintain a session counter and a timer to compute a session rate over the last second. This value will be very useful because it varies instantly and can be used to check thresholds. This value is also reported in the stats in a new "rate" column.
2009-03-05 17:43:00 +00:00
/*
* Local variables:
* c-indent-level: 8
* c-basic-offset: 8
* End:
*/
Reference in New Issue Copy Permalink