Philippe Gerum wrote:
Jan Kiszka wrote:
Gilles Chanteperdrix wrote:
Philippe Gerum wrote:
> Gilles Chanteperdrix wrote:
> > Philippe Gerum wrote:
> > > Likely not this time (keep it cold anyway, who knows); I
strongly suspect a bug in > > > xnarch_switch_to() for all archs but
> > > > Now that you are talking about it, I may be the one who owes
a beer to
> > everyone by first having put a bug in ia64 context-switch code...
> > am not wrong, the bug should be observed on ia64 too.
> > am unable to compile my ia64 kernel right now, so I wrote a patch
> > power PC, and would be glad if some power PC owner could try it.
> > > > Nope, same lockup with hybrid scheduling.
The latency -t 1 crash may be observed on ia64 too.
But it does not seem to be due to the bug I was suspecting in context
What about the PPC world? I saw some SVN commits claiming to fix this
(also for blackfin) - but there was no "Hey, it's fixed now!" on the
Ok... "Hey, it's fixed now!"
Hybrid scheduling (kernel and user-space Xeno threads combination) has
been fixed for ppc32, ppc64, ia64 and the Blackfin. Issue fixed on the
ARM port to come too. Some tests remain to be conducted on the ppc64
though. The rest has already been validated. Fixes are available from
the SVN trunk/.
This said, here is my next Xmas wishlist I'd really appreciate you guys
anticipate from, say 11 months and a couple of weeks: if you have any of
the above archs, please run both the kernel and user-space latency tests
on such hw:
OK, I will do tests on a few PowerPC boards (4xx, 8xx, 8260).
Basically, this boils down to building Jan's timerbench test into the
kernel or as a separate module, then run the following tests on the said
$ sudo ./latency -t0
$ sudo ./latency -t1
$ sudo ./latency -t2
Special note to the ppc32 people: I would be interested in having your
feedback about switching on the ALTIVEC and SPE supports at kernel
level, on platforms that do not have those beasts, and see if all tests
In any case, I'm eventually going to warn about such configurations at
the very least, since relying on FTR fixups right in the middle of the
fast path for all context switches is kind of, mmh, silly?!
Nevertheless, knowing about the result might be important in the future.