From owner-freebsd-current Mon Feb 18 12:22: 5 2002 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id B095737B402 for ; Mon, 18 Feb 2002 12:22:00 -0800 (PST) Received: (from dillon@localhost) by apollo.backplane.com (8.11.6/8.9.1) id g1IKLTM36110; Mon, 18 Feb 2002 12:21:29 -0800 (PST) (envelope-from dillon) Date: Mon, 18 Feb 2002 12:21:29 -0800 (PST) From: Matthew Dillon Message-Id: <200202182021.g1IKLTM36110@apollo.backplane.com> To: Julian Elischer Cc: current@FreeBSD.ORG Subject: Re: Patch to improve mutex collision performance References: Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG : :I can't see any major problem with this but I can't help thinking that :there must be one.. on UP the question is: "who is going to :release the lock if no-one is runnable?" An interrupt, of course. Wakeups don't happen out of thin air! This is true of 1.x, 2.x, 3.x, 4.x, 5.x, UP, and SMP. Something needs to trigger the event that causes the wakeup to occur. :can you detail in more clarity the flip-flopping you were seeing? Basically what is happening is that switch/wakeup overhead is being imposed unnecessarily. There is no need to switch if there is nothing to switch to, and this also causes the other process to not have to wakeup anyone when it releases Giant because process #1 is spinning on it instead of sleeping on it. So you immediate remove four context switches from the critical path. The other problem I saw is actually a fairly typical problem. When you have multiple cpu's running the same program that is making a system call that obtains a mutex, and the mutex spins, the programs will tend to stabilize slightly out of sync of each other so the mutex-release in one occurs just before the mutex-acquire in another. The result is fairly optimal performance for this particular situation even though the mutexes are spinning. However, when the mutex sleeps instead of spins no such stabilization occurs. Sometimes I would run the two-process test and they would operate optimally... obviously they were out of sync enough so there was no mutex contention in the one remaining Giant mutex in userret. Sometimes they would operate non-optimally, showing half the performance. Even worse, this non-optimal performance appears to stabilize.. i.e., it can't break out of it once it gets into it. So what this code does is avoid both the sleep, the context switch, and the wakeup in situations where they are not needed and reduces syscall overhead by about 100% per cpu with 2 cpus. It almost certainly also avoids. - In regards to preemption code, I think this is a separate issue. This case occurs when there are no runnable processes waiting for cpu in the system (i.e. running processes are already on their cpus). -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message