[haiku-development] Re: Disabling CPU disabling
- From: Pawel Dziepak <pdziepak@xxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Sun, 27 Oct 2013 20:36:50 +0100
I see that there are a lot of arguments against removing CPU
disabling, the most convincing seems to be the fact that it is an
unique, Haiku-only feature /and/ the fact that it is a common feature
in other systems :/
However, there are also a bit more valid reasons. Also, I realized how
misleading the functionality of this feature is.
2013/10/25 Jérôme Duval <korli@xxxxxxxxxxxxxxxx>:
> 2013/10/25 Pawel Dziepak <pdziepak@xxxxxxxxxxx>:
>> Since the scheduler code has grown quite big I am trying to remove as
>> much unnecessary logic as possible. The thing that caught my attention
>> is the possibility to disable a logical processor.
>
> A theorical use case would be hotplugging/unplugging a CPU. It's not
> that we plan to support that anytime soon though :)
Unfortunately, current implementation of CPU disabling is nowhere near
any form of CPU hotplug. Disabled CPUs aren't really disabled. The
rest of the kernel (i.e. everything except the scheduler) ignores the
fact that user asked to disable CPU and the logical processor still
may have some work to do (e.g. handle interrupts). The scheduler isn't
much better it still allows pinned thread to run on disabled logical
processors. Finally, the thread running on a CPU that is going to be
disabled is allowed to complete its time slice. Finally, disabling
whole package is not exactly the same thing as disabling logical
processors separately.
2013/10/25 Julian Harnath <julian.harnath@xxxxxxxxxxxxxx>:
> Pawel Dziepak <pdziepak@xxxxxxxxxxx> schrieb:
>> Anyone going to miss that feature?
>
> Well, I always found it pretty cool and unique, a nice demonstration of
> flexibility :-) But yeah, that's probably not a good reason alone.
> Apart from that, it was sometimes useful to me for debugging in
> relation to #8007, to reduce system performance.
When testing kernel it is much better to run Haiku with SMP disabled
than to disable all CPUs but one later. The reason for this I
mentioned earlier, the kernel generally ignores the fact that logical
processor has been disabled. Also, only with SMP disabled additional
assertions will be checked (e.g. in spinlock implementation).
2013/10/25 Andrew Hudson <hudsonco1@xxxxxxx>:
> -----Original Message-----
> From: Pete Goodeve <pete.goodeve@xxxxxxxxxxxx>
> To: haiku-development <haiku-development@xxxxxxxxxxxxx>
> Sent: Thu, Oct 24, 2013 9:59 pm
> Subject: [haiku-development] Re: Disabling CPU disabling
>
>>Please leave it in place. There have been quite a few times where
>>i wanted to check if multithreading in an app could be causing a race or
>>something, or just to see how much its performance is impacted by
>>the number of CPUs
>
> Agreed. This feature is very useful when doing coding for parallel
> processing.
>
> Here's a crude but functional example:
>
> http://haikuware.com/directory/view-details/multimedia/video/miscellaneous/mandelbrotsmp
Testing performance using current implementation of CPU disabling is
very unreliable. Since you don't know the CPU topology you have no
idea what are you actually disabling. E.g. 2 core system with HT,
after disabling half of the logical processors you don't know whether
you have disabled one core or just one SMT unit on each core. And
again, disabled CPU aren't really disabled and may still help (but
yes, not very much) the others with their work.
2013/10/25 Fredrik Andersson <fredrikandersson@xxxxxxx>:
> Just for consideration, this feature is in now way unique to Haiku/BeOS.
> It's available historically for diagnostistic reasons, today it's added to
> more and more systems as it allows some significant energy saving. (Linux can
> only do it via a restart though)
Disabling logical processor for energy saving is and idea flawed from
its very beginning. As I mentioned before, currently, you have no idea
what you are actually disabling. Moreover, because of technologies
like Turbo Boost it is much better (both for performance and power
saving reasons) to balance load on cores evenly. That's also the
tricky part with the small task packing it is good to put small tasks
on one core because the other ones could be then woken up less often,
but only if the tasks are really small and it doesn't result in too
high load on that core. If there is too much load it is better to wake
up more cores and make them running in a lower P state than have one
core running in a P state from Turbo Boost range. The scheduler is
going to do that automatically when in power saving mode so there is
no need for user to interfere with its decisions.
To sum it up. I am not going to remove CPU disabling. I am going to
implement it in a proper way so that in (distant) future it could be
used easily when implementing CPU hotplug. It is a low priority task,
though, so for now it will stay broken in my branch.
Paweł
Other related posts:
