Date: Fri, 8 Oct 1999 17:53:07 -0700 (PDT) From: Alfred Perlstein <bright@wintelcom.net> To: smp@freebsd.org Subject: optimizing the idle-loop and more mp stuff Message-ID: <Pine.BSF.4.05.9910081715240.8080-100000@fw.wintelcom.net>
next in thread | raw e-mail | index | archive | help
I've been looking at the mplock stuff for a while now and I was wondering if someone could clarify some observations and assumptions I have. 1) the idle loop that zero's pages has the mplock up so that it can't even run on an idle CPU. It seems to me that this could be fixed by ripping some code from pmap_zero_page() specifically to map the page in and _then_ releasing the mplock, zero'ing the page and aquiring the mplock again. perhaps even grabbing several pages, mapping them in and the zero'ing them all in one sweep to lower the overhead of mplock manipulation. Is it also possible that our 'optimized' bzero routines aren't trully SMP safe? (using npx or some other trick?) 2) all syscalls grab the mplock on entry. The limitations from moving to linux's SMP (which seems to be just putting kernel_lock() at the start of each syscall and kernel_unlock() at the end) seem to be: . the copyin() code for the syscall arguments solution: special copyin that grabs the mplock on a pagefault . fork() issues that I need to think more about solution: hmm? :) Perhaps part of the fork() return path must grab the mplock before running out of the kernel, or perhaps the process just spins on the mplock after being crafted which I assume is almost already the case. . singular scratch areas used by the kernel solution: per-process scratch areas. thanks, -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.9910081715240.8080-100000>