Date: Sun, 12 Dec 2010 12:48:20 -0600 From: Alan Cox <alan.l.cox@gmail.com> To: Venkatesh Srinivas <vsrinivas@dragonflybsd.org> Cc: freebsd-hackers@freebsd.org Subject: Re: i386 pmap_zero_page() late sched_pin()? Message-ID: <AANLkTikvYTerv4f7TO06R86xO_9FLmM8h0mrVJF9HXj2@mail.gmail.com> In-Reply-To: <alpine.LFD.2.00.1012121130220.25740@centaur.acm.jhu.edu> References: <alpine.LFD.2.00.1012121130220.25740@centaur.acm.jhu.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, Dec 12, 2010 at 10:40 AM, Venkatesh Srinivas < vsrinivas@dragonflybsd.org> wrote: > Hi, > > In the i386 pmap's pmap_zero_page(), there is a fragment... > > sysmaps = &sysmaps_pcpu[PCPU_GET(cpuid)]; > mtx_lock(&sysmaps->lock); > * sched_pin(); > /*map the page we mean to zero at sysmaps->CADDR2*/ > pagezero(sysmaps->CADDR2); > sched_unpin(); > > I don't know this bit of code too well, so I don't know if the sched_pin() > being where it is is okay or not. My first reading says its not okay; if a > thread is moved to another CPU before it is able to pin, it will use the > wrong sysmaps structure. Is this the case? Is it alright that the wrong > sysmap structure is used? > > Oh, Nathaniel Filardo (nwf@cs.jhu.edu) first spotted this, not I. > > This isn't a bug. There is nothing about the code that mandates that processor i must always use sysmap entry i. In the unlikely event that the thread migrates from processor X to processor Y before the sched_pin(), the mutex on sysmap entry X will prevent it from being used by processor X until processor Y is done with it. So, it doesn't matter to correctness that the "wrong" sysmap entry is used, and it is extremely unlikely to matter to performance. Alan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTikvYTerv4f7TO06R86xO_9FLmM8h0mrVJF9HXj2>