Message-ID: <3EFC9E4F.9070405@colorfullife.com>
Date: Fri, 27 Jun 2003 21:43:11 +0200
From: Manfred Spraul <manfred@colorfullife.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030313
MIME-Version: 1.0
To: "Chen, Kenneth W" <kenneth.w.chen@intel.com>
CC: linux-kernel@vger.kernel.org
Subject: Re: ipc semaphore optimization
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1716
Lines: 38

Chen wrote:

>What we are proposing here is to merge the portion of the code in the
>bottom part of sys_semtimedop() (code that gets executed when a sleeping
>process gets woken up) into update_queue() function.  The benefit is two
>folds: (1) is to reduce redundant calls to try_atomic_semop() and (2) to
>increase efficiency of finding eligible processes to wake up and higher
>concurrency for multiple wake-ups.
>  
>
Interesting. I'm not sure if you noticed it, but your patch backs out a 
change from Christoph Rohland from 1998, probably from SAP DB benchmarking:

linux/ipc/sem.c:
 * - The previous code had two flaws:
 *   1) It actively gave the semaphore to the next waiting process
 *      sleeping on the semaphore. Since this process did not have the
 *      cpu this led to many unnecessary context switches and bad
 *      performance. Now we only check which process should be able to
 *      get the semaphore and if this process wants to reduce some
 *      semaphore value we simply wake it up without doing the
 *      operation. So it has to try to get it later. Thus e.g. the
 *      running process may reacquire the semaphore during the current
 *      time slice. If it only waits for zero or increases the semaphore,
 *      we do the operation in advance and wake it up.

Perhaps the O(1) scheduler is better at handling the thread switches 
than the old scheduler. Could you include an update of the comments into 
your patch?

--
    Manfred

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/