mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Odzioba, Lukasz" <lukasz.odzioba@intel.com>
To: Guenter Roeck <linux@roeck-us.net>, Jean Delvare <jdelvare@suse.de>
Cc: "Yu, Fenghua" <fenghua.yu@intel.com>,
	"lm-sensors@lm-sensors.org" <lm-sensors@lm-sensors.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH] hwmon: coretemp: use list instead of fixed size array for temp data
Date: Fri, 17 Jul 2015 19:23:44 +0000	[thread overview]
Message-ID: <D6EDEBF1F91015459DB866AC4EE162CCF76C3A@IRSMSX103.ger.corp.intel.com> (raw)
In-Reply-To: <55A94303.5040805@roeck-us.net>

On Friday, July 17, 2015 8:02 PM Guenter Roeck wrote:
> Please explain why krealloc() won't work, why using krealloc(() would
> result in a larger memory footprint than using lists, and why disabling
> CPUs would require any action in the first place.

It will work, but it can use more memory for cpus with many cores.
If you have just one core visible to the kernel with id 59 
(i.e. the rest are disabled by hardware) out of 60-core cpu then you
have to allocate an array of 60 pointers instead of just one element of
the list. Of course you can say that for cpu with just one core list will
use 3x the memory needed by array and that's true. I see no point in 
arguing which case is more important, let's move on.

> "yet" is a key term here. Presumably you have insider information.

No I don't have such information.

> Unless you can share this information, I don't see the point of replacing
> an O(1) algorithm with O(n), especially since there is a relatively simple
> alternative available to support more CPUs.

Ok I understand that, and somewhat agree with that.

> Unless you clarify that Intel will introduce CPU IDs which cannot be used
> as array index because they are too sparse, I don't really see how the list 
> solution would consume less memory than an array of pointers, even if the 
> array is somewhat sparse. After all, a list consumes at least two pointers 
> per entry.

Ok maybe I should state that clearer, my bad. For my purposes removing limit
of supported cores or bumping it is all I need. Removing limit of maxid is 
just nice to have - nothing really practical any soon I guess.

I based this patch on Kirill's which used lists and then you guys did not
say that this is a bad idea, so I tried to solve problems reported earlier
- deadlocks and race conditions and submitted another version.

Maybe if I would start from scratch I would not ran into all this.
In general it is good that you found the weak point of it.

Thanks,
Lukas


  reply	other threads:[~2015-07-17 19:23 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-15 16:04 Lukasz Odzioba
2015-07-15 21:07 ` Jean Delvare
2015-07-16 13:17   ` Odzioba, Lukasz
2015-07-17 16:55     ` Guenter Roeck
2015-07-17 17:28       ` Odzioba, Lukasz
2015-07-17 18:01         ` Guenter Roeck
2015-07-17 19:23           ` Odzioba, Lukasz [this message]
2015-07-17 21:33             ` Jean Delvare
2015-07-17 19:11         ` Jean Delvare
2015-07-17 19:36           ` Guenter Roeck
2015-07-17 21:25             ` Jean Delvare
  -- strict thread matches above, loose matches on Subject: below --
2012-05-01 21:25 [PATCH] hwmon: coretemp: fix oops on cpu unplug Guenter Roeck
2012-05-02 15:10 ` [PATCH] hwmon: coretemp: use list instead of fixed size array for temp data Kirill A. Shutemov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=D6EDEBF1F91015459DB866AC4EE162CCF76C3A@IRSMSX103.ger.corp.intel.com \
    --to=lukasz.odzioba@intel.com \
    --cc=fenghua.yu@intel.com \
    --cc=jdelvare@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=lm-sensors@lm-sensors.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®