Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Commit40d3503

Browse files
committed
Avoid floating-point underflow while tracking buffer allocation rate.
When the system is idle for awhile after activity, the "smoothed_alloc"state variable in BgBufferSync converges slowly to zero. With standardIEEE float arithmetic this results in several iterations with denormalizedvalues, which causes kernel traps and annoying log messages on somepoorly-designed platforms. There's no real need to track such small valuesof smoothed_alloc, so we can prevent the kernel traps by forcing it to zeroas soon as it's too small to be interesting for our purposes. This issueis purely cosmetic, since the iterations don't happen fast enough for thekernel traps to pose any meaningful performance problem, but still it seemsworth shutting up the log messages.The kernel log messages were previously reported by a number of people,but kudos to Greg Matthews for tracking down exactly where they were comingfrom.
1 parenta1a233a commit40d3503

File tree

1 file changed

+12
-1
lines changed

1 file changed

+12
-1
lines changed

‎src/backend/storage/buffer/bufmgr.c

Lines changed: 12 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1473,7 +1473,18 @@ BgBufferSync(void)
14731473
smoothing_samples;
14741474

14751475
/* Scale the estimate by a GUC to allow more aggressive tuning. */
1476-
upcoming_alloc_est=smoothed_alloc*bgwriter_lru_multiplier;
1476+
upcoming_alloc_est= (int) (smoothed_alloc*bgwriter_lru_multiplier);
1477+
1478+
/*
1479+
* If recent_alloc remains at zero for many cycles, smoothed_alloc will
1480+
* eventually underflow to zero, and the underflows produce annoying
1481+
* kernel warnings on some platforms. Once upcoming_alloc_est has gone
1482+
* to zero, there's no point in tracking smaller and smaller values of
1483+
* smoothed_alloc, so just reset it to exactly zero to avoid this
1484+
* syndrome. It will pop back up as soon as recent_alloc increases.
1485+
*/
1486+
if (upcoming_alloc_est==0)
1487+
smoothed_alloc=0;
14771488

14781489
/*
14791490
* Even in cases where there's been little or no buffer allocation

0 commit comments

Comments
 (0)

[8]ページ先頭

©2009-2025 Movatter.jp