Matthew Dillon wrote:
> :It's also very important that the scheduler becomes MP safe.
> I forgot that one. Yes, absolutely.
> :> we can do any of this stuff, though. A previous
> :> attempt to optimizing just #3 in uiomove did not
> :I wasn't around when this was attempted, did the code only
> :touch the BGL when the amount to copy was greater than let's
> :say 2k? Or was the bgl toggled on every uiomove?
> BDE tried his hand at this and spent a few minutes working
> up a simple patch that essentially turned off the bgl
> during the uiomove and then turned it back on again. I
> messed around with it for a while and ran a bunch of tests
> and just didn't get the expected performance improvement.
> I think there was a lock inversion problem too but I'm not
> I concluded that the problem was that there were too many
> other places in the code path that held the BGL and turning
> it off in that one place was not sufficient.
> :It'd be great to get that code committed asap, it's really a keen
> :observation and the benefit are immediate and un-obtrusive.
> Ok, I will. I have put the adjusted patch up for a final
> review at:
> in the second section 'SMP PatchSet ....', the file is:
> I've been running the patch for several weeks without
> any problem.
I have a problem with this portion of the smp-patch-02.diff:
RCS file: /home/ncvs/src/sys/sys/lock.h,v
retrieving revision 1.16
diff -u -r1.16 lock.h
--- lock.h 1999/08/28 00:51:50 1.16
+++ lock.h 1999/11/18 08:22:37
@@ -208,4 +208,15 @@
#endif /* NCPUS == 1 */
#endif /* !SIMPLELOCK_DEBUG */
+#define GET_SYSCALL_LOCK get_mplock()
+#define REL_SYSCALL_LOCK rel_mplock()
+#else /* !SMP */
+#endif /* SMP */
#endif /* !_LOCK_H_ */
This appears to be unrelated to the MPgetlock etc code so it may not be
intended to be there. However, the problem is that it looks like it's
exposing more "#ifdef SMP" to modules.. This is a problem if we have to
have a SMP vs non-SMP set of modules for 4.0-RELEASE, especially for things
like OSS. Obviously I haven't seen the code, but please keep this in mind.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-smp" in the body of the message