Skip Menu |

This queue is for tickets about the Apache-SizeLimit CPAN distribution.

Report information
The Basics
Id: 93757
Status: new
Priority: 0/
Queue: Apache-SizeLimit

People
Owner: Nobody in particular
Requestors: zefram [...] fysh.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: no need for Linux::Smaps
Date: Tue, 11 Mar 2014 17:36:17 +0000
To: bug-Apache-SizeLimit [...] rt.cpan.org
From: Zefram <zefram [...] fysh.org>
Using Linux::Smaps is a bad idea, because it's very slow. I think the problem perceived with statm was largely the result of using the wrong field in it, as described in [rt.cpan.org #73752]. I think that with that fixed, Apache-SizeLimit should use statm in all cases on Linux. Attached patch excises the use of Linux::Smaps. -zefram

Message body is not shown because sender requested not to inline it.

Subject: Re: [rt.cpan.org #93757] AutoReply: no need for Linux::Smaps
Date: Thu, 13 Mar 2014 11:11:59 +0000
To: Bugs in Apache-SizeLimit via RT <bug-Apache-SizeLimit [...] rt.cpan.org>
From: Zefram <zefram [...] fysh.org>
Addendum: Having looked closer at Linux::Smaps, I've determined that A-SL's use of it actually suffers a similar problem to the use of statm. The {shared,private}_{clean,dirty} totals all only count resident pages. Their sum matches the "rss", not the "size". So, like the old version of _linux_size_check, _linux_smaps_size_check provides the wrong statistics on which to base a decision about process termination, as a process will appear artificially cheap if swapping starts in earnest. This is a stronger reason to eschew the smaps logic than its slowness. The patch that I provided in my first message didn't just remove the smaps code, it also contained the fix for the statm code. That wasn't what I intended to send. Attached patch has the smaps removal on its own. -zefram

Message body is not shown because sender requested not to inline it.