https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399
--- Comment #124 from Don Lewis <truck...@freebsd.org> --- (In reply to Nils Beyer from comment #121) I let it run overnight here and got 16000+ passes w/o error. I also see the same variation: 16680: Tue Jul 25 08:04:36 PDT 2017: OK 16640: Tue Jul 25 08:04:36 PDT 2017: OK 16678: Tue Jul 25 08:04:36 PDT 2017: OK 16699: Tue Jul 25 08:04:37 PDT 2017: OK 16719: Tue Jul 25 08:04:37 PDT 2017: OK 16813: Tue Jul 25 08:04:37 PDT 2017: OK 16684: Tue Jul 25 08:04:37 PDT 2017: OK 16687: Tue Jul 25 08:04:37 PDT 2017: OK 16737: Tue Jul 25 08:04:37 PDT 2017: OK 16758: Tue Jul 25 08:04:37 PDT 2017: OK This isn't too surprising since there are more threads than cores and the scheduler won't be totally fair about keeping the load on each core balanced, so the wall clock time for each process will vary a bit. Over time there will be some dispersion in the number of processes executed by each run1 instance. I don't know whether the segfaults in this example count as a bug or not. The architecture spec should say that for this sort of thing you should do A, B, and C. It may be the case that if you don't strictly follow the spec that your code will run on CPU A, but not CPU B. I forgot to mention the uop cache. I'm wondering if it automatically gets invalidated when writes are detected to the instruction locations that it has cached decoded instructions for. Note this statement about self-modifying code: The micro-op cache is filled by the conventional instruction-fetch-and-decode pipeline, but it’s neither inclusive nor exclusive of the L1 instruction cache. As a result, self-modifying code is more difficult, as it must check and potentially invalidate both caches. Since the TLBs are earlier in the pipeline, the micro-op cache may be physically addressed, unlike Intel’s virtually addressed micro-op cache. that I found here: http://www.neogaf.com/forum/showthread.php?t=1342455&page=1 I have read that AMD has been suggesting that people having stability problems try disabling the uop cache. The BIOS on my board does not have an option for that. I think this code is trying to test for the ASLR problem that at lot of Linux users have run into. It's a poor match for that, though. ASLR doesn't use self modifying code, it always starts with a fresh process each time and just maps stuff into randomly chosen locations each time. If you run the same program several times, the memory contents might look like A B C B A C etc. To the CPU this is shouldn't be any different than running cat, make, and sh. -- You are receiving this mail because: You are the assignee for the bug. _______________________________________________ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
