Date: Fri, 8 Jul 2016 13:02:58 +0100 From: RW <rwmaillists@googlemail.com> To: freebsd-hackers@freebsd.org Subject: Re: Why kinfo_getvmmap is sometimes so expensive? Message-ID: <20160708130258.7b772558@gumby.homeunix.com> In-Reply-To: <6193bbf3-39cd-abaa-a5e4-0480c40dac55@rawbw.com> References: <e6dc27c0-0454-0666-b3e1-887bd116a847@rawbw.com> <20160707001913.GJ38613@kib.kiev.ua> <6193bbf3-39cd-abaa-a5e4-0480c40dac55@rawbw.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 7 Jul 2016 15:32:28 -0700 Yuri wrote: > On 07/06/2016 17:19, Konstantin Belousov wrote: > > To calculate residency count for the process map entries, kernel > > has to iterate over all pages. This operation was somewhat > > optimized in 10.3 and HEAD, particularly for the large sparce > > mappings. But for large populated mappings there is no other way > > then to check each page. > > > > You may confirm my hypothesis by setting sysctl > > kern.proc_vmmap_skip_resident_count to 0 and see whether the CPU > > consumption changed. Of course, you will not get the resident count > > in the returned structure, after the knob is tweaked. > > > When people raise the question of why malloc library doesn't unmap > the memory, developers there usually say that they call > madvise(MADV_FREE) and this is as good as unmap. It's better than unmapping because freed memory is commonly re-malloced shortly after it's freed. > But this example > shows that this isn't quite the case on the FreeBSD, and unmapping is > better. That doesn't mean it's better in general.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160708130258.7b772558>