Date: Wed, 01 Sep 2010 12:04:51 -0500 From: Alan Cox <alc@rice.edu> To: mdf@FreeBSD.org Cc: freebsd-current@freebsd.org, Jeff Roberson <jroberson@jroberson.net> Subject: Re: sched_pin() bug in SCHED_ULE Message-ID: <4C7E87B3.50104@rice.edu> In-Reply-To: <AANLkTinA66XZ%2BjS11B3evNhWnFnyrxr0Lxa3onQYKVUu@mail.gmail.com> References: <AANLkTin6V9pc3d7ifyOmR2V-H5-g_AQFji-LbZzWfAKM@mail.gmail.com> <AANLkTim9qSn_g=1dM6P0xfV=%2B616jMygPDbmM7RkyWGO@mail.gmail.com> <AANLkTinu9MW5Ckd%2BmXE-s8t8QvbYtsAHC9FNwtfOK%2BAF@mail.gmail.com> <201009010950.00422.jhb@freebsd.org> <AANLkTinA66XZ%2BjS11B3evNhWnFnyrxr0Lxa3onQYKVUu@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
mdf@FreeBSD.org wrote: [snip] > I will test this patch out; thanks for the help! > > Two questions: > > 1) How does a thread get moved between CPUs when it's not running? I > see that we change the runqueue for non-running threads that are on a > runqueue. Does the code always check for THREAD_CAN_SCHED when adding > a sleeping thread to a runqueue on wakeup? > > 2) I assume sched_switch() runs a lot more often than sched_pin() or > sched_affinity(), so it would make sense to add any performance > penalty of increased work in either of those places than in the > scheduler. I suppose the two memory references for THREAD_CAN_MIGRATE > and THREAD_CAN_SCHED won't be that expensive. > sched_pin() gets used a fair amount on i386 for creating temporary mappings in order to avoid the need for system-wide TLB shootdowns. The use cases range from the fast path for pipes to page zeroing. Alan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C7E87B3.50104>