Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755621AbbGQR20 (ORCPT ); Fri, 17 Jul 2015 13:28:26 -0400 Received: from mga11.intel.com ([192.55.52.93]:32579 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755425AbbGQR2Y convert rfc822-to-8bit (ORCPT ); Fri, 17 Jul 2015 13:28:24 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.15,497,1432623600"; d="scan'208";a="730879788" From: "Odzioba, Lukasz" To: Guenter Roeck , Jean Delvare CC: "Yu, Fenghua" , "lm-sensors@lm-sensors.org" , "linux-kernel@vger.kernel.org" Subject: RE: [PATCH] hwmon: coretemp: use list instead of fixed size array for temp data Thread-Topic: [PATCH] hwmon: coretemp: use list instead of fixed size array for temp data Thread-Index: AQHQvxgEYODiPG1VaU2e2NNrUiUAmJ3c9ZYAgADv3yCAAe47gIAAE0sg Date: Fri, 17 Jul 2015 17:28:20 +0000 Message-ID: References: <1436976253-4810-1-git-send-email-lukasz.odzioba@intel.com> <20150715230734.76347af2@endymion.delvare> <55A93365.4000702@roeck-us.net> In-Reply-To: <55A93365.4000702@roeck-us.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.181] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1551 Lines: 35 From: Guenter Roeck [mailto:linux@roeck-us.net] On Friday, July 17, 2015 6:55 PM Guenter Roeck wrote: > You don't really explain why your approach would be better than > allocating an array of pointers to struct temp_data and increasing > its size using krealloc if needed. Let's consider two cases of such implementation: a) we use array of pointers with O(n) access algorithm b) we use array of pointers with O(1) access algorithm In both cases an array will have greater memory footprint unless we implement reallocation ourselves when cpus are disabled which will make code harder to maintain. Case b) does not handle huge core ids and sparse enumeration well - it is still to discuss whether we really need it since there is no such hardware yet. I am not saying that my solution is the best of possible ones. I am saying that "the best" can vary depending on which criteria do you choose from (time, memory, clean code...). Some may say that O(n) is fine unless we have thousands of cores and this code is not on hot path, others may be concerned more about memory on small/old devices. I don't see holy grail here, If you see one please let me know. If you think that we don't have to care so much about memory, then I can create another patch which uses array instead of list. Thanks, Lukas -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/