Date: Wed, 6 Jul 2016 15:12:59 -0700 From: Yuri <yuri@rawbw.com> To: Freebsd hackers list <freebsd-hackers@FreeBSD.org> Subject: Why kinfo_getvmmap is sometimes so expensive? Message-ID: <e6dc27c0-0454-0666-b3e1-887bd116a847@rawbw.com>
next in thread | raw e-mail | index | archive | help
The function getProcessSizeBytes, calculating the total size of the
process, runs once per second. I have two processes of the same kind,
but with the different run history.
Process #1 didn't do much work, its total size is 1.5 GB, google
perftools library says that it currently has 1.2GB allocated.
Process #2 did a lot of work, its total size is 6.9 GB, but most of the
used memory was freed, and google perftools library also says that it
currently has only 1.2GB allocated.
Both processes have about 140 lines in /proc/<pid>/map.
What bothers me is that getProcessSizeBytes run once per second makes
process #1 to consume ~0.5% CPU, and process #2 to consume ~14% CPU.
When I stop running getProcessSizeBytes, CPU times of both processes go
to zero.
Obviously, google perftools doesn't unmap the memory, and the totals of
block sizes in /proc/<pid>/map is much higher for process #2 with about
the same block count. But why does this cause 14% of CPU consumption?
And why another, similar process that goes through about the same number
of blocks only has 0.5% CPU consumption?
uint64_t getProcessSizeBytes() {
int i, cnt = 0;
struct kinfo_vmentry *kvm0, *kvm;
m_uint64_t memSz = 0;
kvm0 = ::kinfo_getvmmap(::getpid(), &cnt);
for (i = 0, kvm = kvm0; i<cnt; i++, kvm++)
memSz += (kvm->kve_end-kvm->kve_start);
free(kvm0);
return (memSz);
}
FreeBSD 10.3
Yuri
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?e6dc27c0-0454-0666-b3e1-887bd116a847>