Hacking Coding vWii 3-core support - everything you need to know.

[papermanzero]

Only to catch up the Linux and Core topic (and the assumption about efficient system usage):

Looking at the WiiU, you don't have a "symmetric core approach" (if the specification is correct).
Maybe the WiiU provides symmetric processing but the architecture concerning the cache is asymmetric (which is relevant for the kernel and the scheduler).

• Broadway based core architecture
• Three cores at 1.243125 GHz
• Symmetric multiprocessing with MESI/MERSI support
• Each core can output up to 3 instructions per clock using superscalar parallelism
• 32-bit integer unit
• 64-bit floating-point (or 2 × 32-bit SIMD, often found under the denomination "paired singles")
• A Total of 3 MB of Level 2 cache in an unusual configuration.
  • Core 0: 512 KB, core 1: 2 MB, core 2: 512 KB

Linux should assign threads to a core based on the load of that core.
A thread which is ready to run will be assigned to the core with lowest load.
However you can change the approach by setting the thread affinity.

Nowadays the scheduling approach in Linux is mostly NPTL, which schedules threads at the same level as processes.
However the Linux kernel doesn't always migrate tasks from busy to idle cores automatically.
Means you have to align tasks to idle cores in order to use the system in an efficient way.

Due to the asymmetric architecture of the WiiU concerning the cache. You have to think about shifting tasks/processes from Core0 or Core 2 to Core 1 to get better performance.
Especially SMPs are using "CPU hopping" which means processes or threads are changing the cores.

If you think about using only Core0 and Core2 for the OS, then you don't have to think about shifting tasks or processes from one core to another (-> symmetric approach).
However if you want to use all 3 cores in an efficient way, you have to align the task and process management to use every core and the available resources in an effective way.
You can use the standard SMP approach for the WiiU but you will potentially lose performance.

That's it from my side

 

[sven42]

Nope, that's not what SMP is. SMP really just means that every CPU can perform the same tasks.
You already get possible performance hits if your two cores don't have a shared L2 cache - which very often is the case for modern CPUs. Linux usually assigns a higher core affinity to the original core of a process so that the cache can be reused unless that process was idle for a long time.
On top of that the L2 cache is managed completely in hardware anyway. If you're running something as complex as Linux you will have no idea what's in the cache at the moment anyways.

It just doesn't make sense to only enable two cores, no matter how you put it. Three cores with cache penalties will still be faster than two cores with an insanely complex scheduler.

 

[papermanzero]

Nope, that's not what SMP is. SMP really just means that every CPU can perform the same tasks.
You already get possible performance hits if your two cores don't have a shared L2 cache - which very often is the case for modern CPUs. Linux usually assigns a higher core affinity to the original core of a process so that the cache can be reused unless that process was idle for a long time.
On top of the the L2 cache is managed completely in hardware anyway. If you're running something as complex as Linux you will have no idea what's in the cache at the moment anyways.

It is a classic Linux SMP approach, but you are still right. And that's why a classic SMP approach shouldn't be used for the WiiU to unleash the whole power. You can use it, but you will limit the performance.
I would agree if we have the same amount of resources for every core. But this is unfortunately not the case, and that makes the situation more complex.

It just doesn't make sense to only enable two cores, no matter how you put it. Three cores with cache penalties will still be faster than two cores with an insanely complex schedular.

That's what the programmer has to decide.
Either I want to enable the whole power (with an aligned assigning method of processes and tasks) or I am accepting the limitations I have due to the NPTL assigning process.

Btw. That's what I already tried to describe yesterday, but I only received bashes...

 

[raulpica]

The self-entitledness of some GBAtemp users leaves me astonished.

I was even telling myself that GBAtemp got a lot better when dealing with high-profile console-hackers, when I started reading this thread since a few pages ago.

...Looks like I was horribly wrong.

 

[sven42]

It is a classic Linux SMP approach, but you are still right. And that's why a classic SMP approach shouldn't be used for the WiiU to unleash the whole power. You can use it, but you will limit the performance.
I would agree if we have the same amount of resources for every core. But this is unfortunately not the case, and that makes the situation more complex.



That's what the programmer has to decide.
Either I want to enable the whole power (with an aligned assigning method of processes and tasks) or I am accepting the limitations I have due to the NPTL assigning process.

Btw. That's what I already tried to describe yesterday, but I only received bashes...

*sigh*

Your problem is that you apparently reject reality and then substitute your own. Yesterday you wanted to create some fancy secure loader with some made up timelines and slowly enabling first two and then three cores.
Now you're telling me that the WiiU is not SMP. Again, the cache doesn't really matter. But let's assume again you were right (you're not): The first step still is to make Linux work with the three cores in vWii mode. If you're still convinced that you get another .5% power by writing some crazy scheduler, sure, go ahead.

 

[jammybudga777]

again another day with bashing each other offfff (lmao)!!!!!!!!!!!!!!!! what a waste

 

[papermanzero]

*sigh*

Your problem is that you apparently reject reality and then substitute your own. Yesterday you wanted to create some fancy secure loader with some made up timelines and slowly enabling first two and then three cores.
Now you're telling me that the WiiU is not SMP. Again, the cache doesn't really matter. But let's assume again you were right (you're not): The first step still is to make Linux work with the three cores in vWii mode. If you're still convinced that you get another .5% power by writing some crazy scheduler, sure, go ahead.

a) I didn't want to create some fancy secure loader (you guys focused on that stuff). I explained a different homebrew approach with the example of a sandbox, and I emphasized that the solution to reach that is irrelevant for the moment.
b) I said it would be better to start with small steps instead of doing a huge amount of work. I argued with an imaginary timeline to demonstrate what I mean.
c) I am not saying WiiU is not SMP. I am saying you shouldn't use the NPTL approach of Linux for the WiiU.
For sure the Cache matters if you want to schedule the processes efficiently. It's somehow a small difference between 2MB Cache and 512KB, isn't it.

But I guess you already did a feasibility phase concerning the performance of the CPU.
Just the same as you said the WiiU is completely symmetric and an Linux SMP can be used without limitations.

...oh man...

 

[sven42]

And again it's obvious that you have absolutely no clue about software and are just babbling some fancy words you heard somewhere.

NPTL is a way of organizing threads, it's not a way of scheduling threads. The layout of the CPU and wether it's SMP or no does not matter at all at that point.

And as it turns out Linux already supports CPUs with different caches sizes in its SMP implementation.

 

[obcd]

The vwii 3 core smp linux will still have the vwii limited memory resources.
So I don't think it will matter much if the performance is not 100% due to 2 of the 3 cores having less L1 cache than the other.
In wiiu mode (not available yet), having 3 cores at twice the vwii mode speed, with all the wiiu memory will likely give a giant performance boost.
Why complaining about fine tuning it's engine, if the car and it's engine are not designed yet?
Devolution might seem like a very secure system, but I am pretty sure that a hacker with the knowledge could break it's anti piracy protection in a couple of days.
As those guys don't support piracy, it hasn't been done yet, not because it's extremely hard to do it.

 

[sven42]

The vwii 3 core smp linux will still have the vwii limited memory resources.
So I don't think it will matter much if the performance is not 100% due to 2 of the 3 cores having less L1 cache than the other.
In wiiu mode (not available yet), having 3 cores at twice the vwii mode speed, with all the wiiu memory will likely give a giant performance boost.
Why complaining about fine tuning it's engine, if the car and it's engine are not designed yet?
Devolution might seem like a very secure system, but I am pretty sure that a hacker with the knowledge could break it's anti piracy protection in a couple of days.
As those guys don't support piracy, it hasn't been done yet, not because it's extremely hard to do it.

Pretty much, yes

I'm getting tired of this argument as well, let's focus on getting Linux with three cores up in vWii and see where that takes us, shall we?

 

[papermanzero]

And again it's obvious that you have absolutely no clue about software and are just babbling some fancy words you heard somewhere.

More than you.

NPTL is a way of organizing threads, it's not a way of scheduling threads. The layout of the CPU and wether it's SMP or no does not matter at all at that point.

And as it turns out Linux already supports CPUs with different caches sizes in its SMP implementation.

Now please describe the difference between organizing and scheduling (both are performed hand-in-hand) .
Linux has not only one SMP implementation.
SMP is only describing the multicore solution for a system. But there a different ways for creating a SMP software or system (LinuxThreads, NPTL, NGPT, etc.).

 

[Jacobeian]

More than you.



Now please describe the difference between organizing and scheduling (both are performed hand-in-hand) .
Linux has not only one SMP implementation.
SMP is only describing the multicore solution for a system. But there a different ways for creating a SMP software or system (LinuxThreads, NPTL, etc.).

organizing = creating threads, allocating memory to threads, assigning priority, deleting threads
scheduling = allocating CPU (s) timeslices to threads during real-time execution

those are two different things


no offense PapermanZero but I think you are typical "theorist" programmer: someone with lot of conceptual ideas and self-acquired certainties but who sadly never achieve (or even start) to develop them for real

I know this is the place where people like spending their time talking in circles and bashing each other but really what is needed is less talking, more real work...

 

[raulpica]

Okay, I'll bring this out. We know that sven42 has done a lot for the Wii, making awesome achievements while at it.
So you, papermanzero, so apt in scorning him and his knowledge of the successor of a system he has hacked open wide, what great stuff did you make?

Please show some examples of your programming prowess. In the case that you haven't got anything to boast about, it'd be more tactful to show some respect to a well-acknowledged developer.

 

[papermanzero]

organizing = creating threads, allocating memory to threads, assigning priority, deleting threads
scheduling = allocating CPU (s) timeslices to threads during real-time execution
those are two different things

Thanks for the definition and these 2 things are exactly what NPTL has to take care about.
The scheduler which will be handled by the Kernel must be controlled via NPTL.
NPTL is therefore using an highly optimized kernel.

But you can read everything in the whitepaper:
http://www.akkadia.org/drepper/nptl-design.pdf

no offense PapermanZero but I think you are typical "theorist" programmer: someone with lot of conceptual ideas and self-acquired certainties but who sadly never achieve (or even start) to develop them for real

I know this is the place where people like spending their time talking in circles and bashing each other but really what is needed is less talking, more real work...

No problem. Let's say it in a different way: I created a lot of private projects but meanwhile I don't have the time and the motivation to do new stuff.

Okay, I'll bring this out. We know that sven42 has done a lot for the Wii, making awesome achievements while at it.
So you, papermanzero, so apt in scorning him and his knowledge of the successor of a system he has hacked open wide, what great stuff did you make?

Please show some examples of your programming prowess. In the case that you haven't got anything to boast about, it'd be more tactful to show some respect to a well-acknowledged developer.

Why is it relevant for the discussion?
There is no doubt about the achievements sven did. It's remarkable.
I am only saying, there are different ways. Ways which are hard and steep and ways which are easy and more comfortable. And also people like sven or even myself, could be on the wrong way independent of the achievements. It doesn't matter what someone did or achieved. It's life.

 

[Jacobeian]

Thanks for the definition and this 2 things are exactly what NPTL has to take care about.
The scheduler who will be handled by the Kernel must be controlled via NPTL.
NPTL is therefore using an highly optimized kernel.

But you can read everything in the whitepaper:
http://www.akkadia.org/drepper/nptl-design.pdf

and that just confirms what I said in my previous post, linking to an outdated pdf you found on wikipedia does not make you an expert, please show us some of your projects related to the subject instead

btw, have you even read the first sentences in the document you linked ?

This document is completely, utterly out of date when it comes to descriptions of the limitations of the current implementation. Everybody referring to this document to document shortcomings of NPTL is either a moron who hasn’t done her/his homework and researched the issue, or is deliberately misleading people as it happens too often with publications done by the Evil from the North-West.

sorry, but I agree with sven42 and I think you have no idea about what you are talking about, NPTL is NOT related to scheduling as it does not provides a scheduler and, more importantly, SMP is a completely separated concept which, even if it can be used by the library, is actually implemented outside it.

 

[papermanzero]

and that just confirm what I said in my previous post, linking to an outdated pdf you found on wikipedia does not make you an expert, please show us some of your projects related to the subject instead

btw, have you even read the first sentences in the document you linked ?

I didn't found it in wikipedia. But anyway...
You can read the implementation of NPTL in other documentations, which are describing exactly the same (so in this case it's not a big difference).

You can take this one, if you would like to have a "newer" document:
http://www.cs.stonybrook.edu/~porter/courses/cse506/f12/slides/nptl-handout.pdf

My projects are not the topic here.
Either you are doing your own research and take a look if the things I posted are correct.
Or you can ignore the stuff and bash.

sorry, but I agree with sven42 and I think you have no idea about what you are talking about, NPTL is NOT related to scheduling as it does not provides a scheduler and, more importantly, SMP is a completely separated concept which, even if it can be used by the library, is actually implemented outside it.

1) NPTL is related to scheduling. Both, organizing and scheduling, must be performed hand-in-hand.
2) SMP is only describing a concept that every core in the CPU has to perform the same tasks without any priority. How to implement SMP depends on the software modules you are using.

 

[Jacobeian]

Just have a look at the presentation you linked...

2nd page... Logical Diagram... see where CPU scheduler is ? that is where scheduling happens. See where thread managing is ? This is what NPTL is about.


5th page... What is a thread library ? Nowhere it says the library handles the scheduling... management, organization, synchronization, that's all it does

honestly, i don't even know what you are arguing about now ^^
my point was just that sven42 statement was absolutely right

 

[papermanzero]

and that just confirms what I said in my previous post, linking to an outdated pdf you found on wikipedia does not make you an expert, please show us some of your projects related to the subject instead

btw, have you even read the first sentences in the document you linked ?

Yes I read it. And I said, it's still valid for the case of scheduling.

2nd page... Logical Diagram... see where CPU scheduler is ? that is where scheduling happens. See where thread managing is ? This is what NPTL is about.

honestly, i don't even know what you are arguing about now ^^
my point was just that sven42 statement was absolutely right

5th page... What is a thread library ? Nowhere it says the library handles the scheduling... management, organization, synchronization, that's all it does

The Local Diagram is Slide 2, not Page 2.

Again, the NPTL is only working in an efficient way, if the scheduler and NPTL are working closely together.
Look at page 3 Slide 6.

NPTL has to create and shift threads from one core to another. This can only be performed if you reschedule.
Therefore an optimized scheduler is needed.
I always said you need a scheduler for scheduling processes and threads.
However NPTL has to instruct the scheduler what to do and when to do.

 

[Jacobeian]

Yes I read it. And I said, it's still valid for the case of scheduling.




The Local Diagram is Slide 2, not Page 2.

Sorry but I'm done arguing with you, your last points show that you don't understand my point and what I was actually arguing about but that's ok.

Can't wait to see your concrete contribution to a WiiU homebrew framework.

 

[papermanzero]

Sorry but I'm done arguing with you, your last points show that you don't understand my point and what I was actually arguing about but that's ok.

Can't wait to see your concrete contribution to a WiiU homebrew framework.

I give you a good advice: Read my last posts carefully and don't interpret stuff.