Date: Tue, 1 Nov 2011 11:28:11 -0400 From: Ryan Stone <rysto32@gmail.com> To: Attilio Rao <attilio@freebsd.org> Cc: mdf@freebsd.org, FreeBSD Current <freebsd-current@freebsd.org>, mlaier@freebsd.org Subject: Re: smp_rendezvous runs with interrupts and preemption enabled on unicore systems Message-ID: <CAFMmRNxh7L2wC1i6tT16PKEQb3C2VOTKc3_JDNZuFbabyay-oQ@mail.gmail.com> In-Reply-To: <CAJ-FndCoYfEGDj2xH=TiEatQ149-AdRON6Aoi_zLiVKbsqb_xA@mail.gmail.com> References: <CAFMmRNwWBE6idGJCsNPago4-N1ohAaCD02_D-LCMzDg8pbjE1A@mail.gmail.com> <CAMBSHm9fxL23Bydnw6_Fned1sNPCq1aYr7As4=a91vVKcW3u1w@mail.gmail.com> <CAJ-FndCoYfEGDj2xH=TiEatQ149-AdRON6Aoi_zLiVKbsqb_xA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Oct 31, 2011 at 7:43 PM, Attilio Rao <attilio@freebsd.org> wrote: > I'm not entirely sure why this exactly breaks though (do you see that > happening with a random rendezvous callback or it is always the > same?), because that just becames a simple function calling on cpu0, > even if I think that there is still a bug as smp_rendezvous callbacks > may expect to have interrupts and preemption disabled and the > short-circuit breaks that assumption. I have only observed the problem with i686_mrstoreone(smp_rendezvous is called from i686_mrstore). I notice that i686_mrstoreone does scary things like disabling the cache and global TLB entries. My experience was that everything got very slow when i686_mrstoreone was preempted, so it easily could be the case that the system because so slow with the cache disabled that it became livelocked. > I don't think that we strictly need the lock here, my preferred > solution would be (only test-compiled): I tried the same thing for the SMP case, and it fixed my problem.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAFMmRNxh7L2wC1i6tT16PKEQb3C2VOTKc3_JDNZuFbabyay-oQ>