Date: Tue, 19 Feb 2002 00:02:22 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Peter Wemm <peter@wemm.org> Cc: Jeroen Ruigrok/asmodai <asmodai@wxs.nl>, Robert Watson <rwatson@FreeBSD.org>, Poul-Henning Kamp <phk@FreeBSD.org>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern kern_time.c Message-ID: <200202190802.g1J82MP59281@apollo.backplane.com> References: <20020219074409.728D03A9A@overcee.wemm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
:> It's not possible to test a proper MP solution for the VM system
:> until we can push Giant down into it from the top down and get a good
:> piece of the I/O path pulled up from the bottom. The best way to push
:> Giant down at this stage is from the system calls down and from the
:> networking and I/O stacks up.
:
:So, you cant do VM lock pushdown because you cant test it? Excuse me, but
:isn't the solution to that the lock instrumentation you've been promoting?
:Why wont that work here? I do not see any reason why it cannot be started
:but left turned off till sufficient callers are not bound up in Giant. You
:are probably one of the few people who can do the VM properly (since you
:obviously dont like Alfred taking a shot at it), why do you have to go and
:reinvent what has already been done?
You are welcome to take a try at it yourself if you think it's that easy.
I'm not stopping you. But otherwise don't assume how easy or hard it is.
:> From my point of view, 80% of the work that has been done in P4 in
:> this area has been a complete and utter waste of time,
:
:Oh great, I guess that means the TrustedBSD and sparc64 ports (which are
:about 80% of the p4 tree usage) must be a complete and utter waste of time
:then. I guess we can can the UDF fs, the pgrp/session locking, tty
:locking, nfs, ia64 etc stuff as well.
:
:Cheers,
:-Peter
:--
:Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au
I haven't seen it, but if there is stuff in there that could be safely
committed to -current then yes, those pieces are wasted sitting in P4.
Especially mutex locking pieces in machine-independant files. With
Giant locked a considerable amount of testing can still be done on
mutex additions since the system will still lockup or panic if you
don't match them up or create a deadlock situation.
But sitting in P4 this sort of testing isn't going to get much exposure.
You know, we aren't just talking about code paths here. We are also
talking about lock interaction. It may seem obvious that Giant can be
removed in high level code like getuid() but even at high levels the
existance or removal of Giant has huge implications in regards to the
timing of the system. As I said before, I am quite comfortable getting
rid of Giant entirely (not instrumenting it) if we were only working
on *ONE* subsystem. I am not comfortable doing it to several at once.
Even my simple removal of Giant in getuid() had unforseen consequences...
the flip flopping problem I mentioned earlier was a direct consequence.
I was able to test it fairly easily with the appropriate sysctl because
I infact did instrument getuid().
System calls like setuid() and far more problematic. Removing Giant
there has consequences. John hasn't instrumented Giant ANYWHERE. Not
just not in getuid(), but not ANYWHERE. So don't give me this bullshit
about John's code not needing to instrument Giant in getuid().
-Matt
Matthew Dillon
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200202190802.g1J82MP59281>