On Mon, Aug 1, 2016 at 3:07 PM, Jun Sun <monkey.j...@gmail.com> wrote: > I looked at the kernel source code again. Kernel currently only detects CPU > features of CPU0 and use it for all other CPUs. In other words, it is > assuming all cores must have the same CPU features, which in a sense is a > form of "enforcing". > > As a result, it is definitely no-no to have cores with different CPU > features, which is what I suspected. Case closed. :) >
Not if you're running http://www.popcornlinux.org/ > Jun > > On Mon, Aug 1, 2016 at 9:27 AM, Jun Sun <monkey.j...@gmail.com> wrote: >> >> Hi, Glenn, thanks for offering your thoughts. I'm sure what you described >> is happening daily. >> >> What I'm more worried about is what if one cluster has NEON instructions >> while the other does not even have. I think app will crash, which is >> obviously a disaster. >> >> If my hypothesis is right, shouldn't kernel even start to enforce that all >> CPUs must have the same features? A quick scan of kernel code seems to >> suggest there is no such enforcement. >> >> Jun >> >> >> On Mon, Aug 1, 2016 at 7:15 AM, Glenn Kasten <gkas...@android.com> wrote: >>> >>> I've heard that the greatest risk is on a big.LITTLE system >>> where the two clusters have different microarchitectures >>> (e.g. A-53 and A-57) and implement the same instruction set. >>> The performance characteristics of the clusters may >>> vary in a more complex way than just being uniformly faster >>> by a constant percentage, for a given clock rate. >>> >>> For example, I've heard NEON code performance can >>> vary in surprising ways between different micro-architectures. >>> So if you hand-optimize your NEON code for one >>> micro-architecture, it may no longer be optimal on another >>> micro-architecture. In that case it is useful for the thread to >>> be able to know at runtime which micro-architecture it is running on. >>> I'm not sure whether Linux kernels expose this information to >>> user mode, especially given that it may change after task migration. >>> >>> This is my understanding; but please feel free to correct >>> or extend if I am misinformed on any of this. >>> >>> >>> On Sunday, July 31, 2016 at 3:19:27 PM UTC-7, monke...@gmail.com wrote: >>>> >>>> One specific example is that if a phone has two clusters. Cores in >>>> one cluster has v8 crypto extension and cores in the other don't. >>>> Will this work? >>>> >>>> My gut feeling is no, since many apps query cpu features at run-time. >>>> And process can migrate among cores. If an app starts on a core with >>>> CE and migrates to another core without CE. Illegal instruction fault >>>> will happen. >>>> >>>> Just wanna confirm if this is indeed the case. Surprisingly google >>>> search did not yield any meaningful answers. >>>> >>>> Cheers. >>>> >>>> Jun >>> >>> -- >>> -- >>> unsubscribe: android-kernel+unsubscr...@googlegroups.com >>> website: http://groups.google.com/group/android-kernel >>> --- >>> You received this message because you are subscribed to the Google Groups >>> "Android Linux Kernel Development" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to android-kernel+unsubscr...@googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. >> >> > > -- > -- > unsubscribe: android-kernel+unsubscr...@googlegroups.com > website: http://groups.google.com/group/android-kernel > --- > You received this message because you are subscribed to the Google Groups > "Android Linux Kernel Development" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to android-kernel+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- -- unsubscribe: android-kernel+unsubscr...@googlegroups.com website: http://groups.google.com/group/android-kernel --- You received this message because you are subscribed to the Google Groups "Android Linux Kernel Development" group. To unsubscribe from this group and stop receiving emails from it, send an email to android-kernel+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
