From owner-freebsd-acpi@FreeBSD.ORG Sun Jun 20 16:19:52 2010 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 07117106564A; Sun, 20 Jun 2010 16:19:52 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 1556F8FC12; Sun, 20 Jun 2010 16:19:50 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA24840; Sun, 20 Jun 2010 19:19:49 +0300 (EEST) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1OQNFN-000IVn-64; Sun, 20 Jun 2010 19:19:49 +0300 Message-ID: <4C1E3FA4.1020009@freebsd.org> Date: Sun, 20 Jun 2010 19:19:48 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100603) MIME-Version: 1.0 To: Alexander Motin References: <4C1E3AE9.3020505@freebsd.org> <4C1E3D44.6020708@FreeBSD.org> In-Reply-To: <4C1E3D44.6020708@FreeBSD.org> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org Subject: Re: cpufreq_curr_sysctl: memory allocation X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 Jun 2010 16:19:52 -0000 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