On Wed, 2005-04-06 at 12:59 +0200, Philip Lawatsch wrote: > Robert Hancock wrote: > > Alan Cox wrote: > > > >> On Sad, 2005-04-02 at 05:50, Robert Hancock wrote: > >> > >>> I'm wondering if one does a ton of these cache-bypassing stores > >>> whether something gets hosed because of that. Not sure what that > >>> could be though. I don't imagine the chipset is involved with any of > >>> that on the Athlon 64 - either the CPU or RAM seems the most likely > >>> suspect to me > >> > >> > >> > >> The glibc version is essentially the "perfect" copy function for the > >> CPU. If you have any bus/memory problems or chipset bugs it will bite > >> you. > > > > > > Anyone have any suggestions on how to track this further? It seems > > fairly clear what circumstances are causing it, but as for figuring out > > what's at fault.. > > Digging through my glibc's source if found that if you memset arrays > <120000 bytes it will use good old mov instructions to do the job. In > case of arrays larger than 120000 bytes it will use movnti instructions > to do the job. > > Thus I refined my test code to use mov for memset regardless of the size > (simply abused glibcs code a little bit) > > -> No crash! > > Then, changing the all the mov to movnti and my machine frags again :( > > It seems that mov'ing does not kill my machine while simply using movnti > does.
movnti also gets a higher bandwidth so that doesn't rule out too much.. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
