Date: Sun, 20 Jun 2010 19:19:48 +0300 From: Andriy Gapon <avg@freebsd.org> To: Alexander Motin <mav@freebsd.org> Cc: freebsd-acpi@freebsd.org Subject: Re: cpufreq_curr_sysctl: memory allocation Message-ID: <4C1E3FA4.1020009@freebsd.org> In-Reply-To: <4C1E3D44.6020708@FreeBSD.org> References: <4C1E3AE9.3020505@freebsd.org> <4C1E3D44.6020708@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
on 20/06/2010 19:09 Alexander Motin said the following: > Andriy Gapon wrote: >> I noticed that cpufreq_curr_sysctl performs a substantial memory allocation and >> deallocation on each call. Its size is CF_MAX_LEVELS * sizeof(*levels), which >> is ~24KB. This happens even for read-only calls to just query current level. >> And such calls happen quite frequently when powerd is running. > > Worse is that it not just consumes time, but causes a bunch or TLB flush > IPIs on free(). For read-only call it doesn't even needs CF_MAX_LEVELS * > sizeof(*levels). sizeof(*levels) seems should be enough there. May be > then it fits into some existing UMA zone, minimizing penalty. Yes, exactly, for R/O case only one level structure gets populated. >> I think that this is an unnecessary and avoidable load for VM system. >> Couldn't a buffer be preallocated in sc and re-used for the calls? >> Even if not, for some reason, then wouldn't it be better to have a dedicated uma >> zone for that rather than doing malloc+free? > > Dedicated rarely used UMA zone may eat much more memory then it is > needed on SMP. I agree, but I hope that a single buffer should be sufficient. As I understand, all sysctl operate under Giant unless specifically flagged otherwise. And I don't see any code to explicitly handle concurrent invocations in cpufreq_curr_sysctl. -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C1E3FA4.1020009>