On 3 June 2013 10:16, Ingo Molnar <mingo@xxxxxxxxxx> wrote: > > * Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote: > >> On Fri, May 31, 2013 at 08:09:17AM +0400, Max Filippov wrote: >> > Hi Peter, >> > >> > On Wed, May 29, 2013 at 9:51 PM, Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote: >> > > What about something like this? >> > >> > With that patch I still get mtest05 firing my TLB/PTE incoherency >> > check in the UP PREEMPT_VOLUNTARY configuration. This happens after >> > zap_pte_range completion in the end of unmap_region because of >> > rescheduling called in the following call chain: >> >> OK, so there two options; completely kill off fast-mode or something >> like the below where we add magic to the scheduler :/ >> >> I'm aware people might object to something like the below -- but since >> its a possibility I thought we ought to at least mention it. >> >> For those new to the thread; the problem is that since the introduction >> of preemptible mmu_gather the traditional UP fast-mode is broken. >> Fast-mode is where we free the pages first and flush TLBs later. This is >> not a problem if there's no concurrency, but obviously if you can >> preempt there now is. >> >> I think I prefer completely killing off fast-mode esp. since UP seems to >> go the way of the Dodo and it does away with an exception in the >> mmu_gather code. >> >> Anyway; opinions? Linus, Thomas, Ingo? > > Since UP kernels have not been packaged up by major distros for years, and > since the live-patching of SMP kernels (the SMP alternative-instructions > patching machinery) does away with a big chunk of the SMP cost, I guess UP > kernels are slowly becoming like TINY_RCU: interesting but not really a > primary design goal? > > ( Another reason for reducing SMP vs. UP complexity in this area would be > the fact that we had a few bad regressions lately - the TLB code is not > getting simpler, and bugs are getting discovered and fixed slower. ) > > At least that's the x86 perspective. ARM might still see it differently? On ARM there is a lot of ongoing work on single zImage for multiple SoCs and this implies SMP kernels. There is an SMP_ON_UP feature which does run-time code patching to optimise the UP case in a few places. Regarding tlb_fast_mode(), the ARM-specific implementation is always 0 on ARMv7 even if UP because of speculative TLB loads (the MMU could pretty much act as a separate processor). Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-arch" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
