From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4641F7A4.50105@domain.hid> Date: Wed, 09 May 2007 18:32:36 +0200 From: Gilles Chanteperdrix MIME-Version: 1.0 References: <22908039.1178707932628.JavaMail.ngmail@domain.hid> <1178727256.11688.35.camel@domain.hid> In-Reply-To: <1178727256.11688.35.camel@domain.hid> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-help] Xenomai and futexes - Native API optimized for user space only applications List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: rpm@xenomai.org Cc: xenomai@xenomai.org, "M. Koehrer" Philippe Gerum wrote: > On Wed, 2007-05-09 at 12:52 +0200, M. Koehrer wrote: > >>Hi everybody, >> >>I am using Xenomai for a high performance real time simulation system. >>All of the simulation code is executed within user space. One application is running that consists >>of several Xenomai real time threads. >>For performance reasons I am always using the latest PC technology available (which is currently >>Pentium D or Core2Duo PCs, we are thinking even of using quad-core CPUs). >>There has to be a kind of thread synchronisation e.g. when accessing shared data. >>Hardware I/O is done via rtnet or via PCI I/O boards that work in user space aswell (PCI memory >>mapped into the user space). >>This is done e.g. by using semaphores, mutexes et.c >>I like the Xenomai-native skin as it provides a very clear API that is easy to use. >>However, for a user space only application it is a performance killer, that all API calls >>lead to a mode switch from user to kernel space. Each API call takes about 1-2 microseconds (us) >>on my PC which is really expensive. >>Especially when inter process communication is used to protect the access to shared data >>it is mostly the case that the calling thread does not have to wait. In this situation there is no >>need for a context switch. The API call did not lead to a rescheduling of the available tasks. >>And for this the required 1-2 us do really hurt. >> >>Thus my question/proposal is if there is a plan to use a "variant" of the native API that is optimized for >>user space only applications. In this case e.g. futexes can be used. If there is a need to >>reschedule to another task it is fine to "invest" the 2us but it can be avoided mostly which should >>increase the overall performance dramatically. >>This would lead to a library where a big part of the functionality is handled directly in the library >>(in user space). Currently the skin passes the (user space) API call via a Xenomai System call >>to the kernel space to execute there the actual functionality. >> >>Thanks for any feedback on this proposal. > > > Yes, this is the way to go. It's the kind of rework introduced by the > NPTL for the glibc, and there is no reason to pay the kernel/user space > transition when no contention exists on the synch object. > > I'm not sure the cost is as much as 2 us, unless you don't use the > sysenter/sysexit protocol for syscalls Xenomai manages properly > (--enable-x86-sep). It seems you are going through the ancient 0x80 > exception vector, but still, I agree that the point remains: no > contention should mean no transition to kernel. > > We could not use futexes, because we don't want to depend on the vanilla > infrastructure, which would lead to unbounded latencies. The point is > about properly sharing a piece of data between both spaces for each > synch object, We could have a "sync object area" where all atomic counters would live, that would be mapped into real-time processes address space, the sync object would then only contain an index in this area. This would mean that the number of sync objects is limited, but it is a restriction far more acceptable than to allocate and share a full page by sync object. > and have some user-space accessible atomic ops to operate > on them. That's the simplest part, the other, more complex one is to > invest the time needed to achieve this (for all archs that may run this > way, i.e. not all archs Xenomai supports do have atomic ops available > from user-space, but that's not the majority though). For all archs, and for all skins. -- Gilles Chanteperdrix