Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S263623AbVBCUs6 (ORCPT ); Thu, 3 Feb 2005 15:48:58 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S263579AbVBCUso (ORCPT ); Thu, 3 Feb 2005 15:48:44 -0500 Received: from mx2.elte.hu ([157.181.151.9]:14025 "EHLO mx2.elte.hu") by vger.kernel.org with ESMTP id S263174AbVBCUse (ORCPT ); Thu, 3 Feb 2005 15:48:34 -0500 Date: Thu, 3 Feb 2005 21:47:11 +0100 From: Ingo Molnar To: Con Kolivas Cc: Paul Davis , "Bill Huey (hui)" , "Jack O'Quin" , Nick Piggin , linux , rlrevell@joe-job.com, CK Kernel , utz , Andrew Morton , alexn@dsv.su.se, Rui Nuno Capela , Chris Wright , Arjan van de Ven Subject: Re: [patch, 2.6.11-rc2] sched: RLIMIT_RT_CPU_RATIO feature Message-ID: <20050203204711.GB25018@elte.hu> References: <200502031420.j13EKwFx005545@localhost.localdomain> <4202876F.3010302@kolivas.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4202876F.3010302@kolivas.org> User-Agent: Mutt/1.4.1i X-ELTE-SpamVersion: MailScanner 4.31.6-itk1 (ELTE 1.2) SpamAssassin 2.63 ClamAV 0.73 X-ELTE-VirusStatus: clean X-ELTE-SpamCheck: no X-ELTE-SpamCheck-Details: score=-4.9, required 5.9, autolearn=not spam, BAYES_00 -4.90 X-ELTE-SpamLevel: X-ELTE-SpamScore: -4 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1348 Lines: 29 * Con Kolivas wrote: > > * real inter-process handoff. i am thinking of something like > > sched_yield(), but it would take a TID as the target > > of the yield. this would avoid all the crap we have to > > go through to drive the graph of clients with FIFO's and > > write(2) and poll(2). Futexes might be a usable > > approximation in 2.6 (we are supporting 2.4, so we can't > > use them all the time) > > yield_to(tid) should not be too hard to implement. Ingo? What do you > think? i dont really like it - it's really the wrong interface to use. Futexes are a much better locking/signalling interface. yield_to() would not be available in 2.4 either. If the apropriate pthread objects are used then libpthread will do it more or less optimally on 2.4 too, while on 2.6 they'd be perfectly fine and based on futexes. If 2.4 is not an issue then a good, futex-based inter-process API is POSIX 1003.1b semaphores (the sem_init()/sem_*() APIs). But if it should work inter-process on non-futex kernels too, then only pthread spinlocks will do it. Ingo - 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/