[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: [rtl] Low-latency patches working GREAT (<2.9ms audio latency),see testresults ,but ISDN troubles
- To: yodaiken@fsmlabs.com
- Subject: Re: [rtl] Low-latency patches working GREAT (<2.9ms audio latency),see testresults ,but ISDN troubles
- From: Andrea Arcangeli <andrea@suse.de>
- Date: Mon, 6 Sep 1999 09:43:49 +0200 (CEST)
- Cc: Ingo Molnar <mingo@chiara.csoma.elte.hu>, yodaiken@chelm.cs.nmt.edu, Alan Cox <alan@lxorguk.ukuu.org.uk>, sbenno@gardena.net, linux-kernel@vger.rutgers.edu, linux-sound@vger.rutgers.edu, alsa-devel@alsa-project.org, sct@redhat.com, torvalds@transmeta.com, audiality@swipnet.se, est@hyperreal.org, nra02596@norran.net, pbd@op.net, rtl@rtlinux.cs.nmt.edu, keil@isdn4linux.de
- In-Reply-To: <19990904144101.A16690@hq.fsmlabs.com>
On Sat, 4 Sep 1999 yodaiken@fsmlabs.com wrote:
>on a uniprocessor. sct pointed out that reschedule_idle
>is very conservative about setting need_resched and this makes Ingo
>correct when he stated that need_resched>0 means that we really do need
>to resched. I'd be happier with some big database tests, and I really think
IMHO this is not the point at all.
need_resched == 1 means you _have_ to reschedule ASAP careless about the
scheduler algorithm at all.
>that database performance should be checked before any such change goes
>into the kernel, but for now, I was flat out wrong.
If honouring the need_resched bit is decreasing performances than it means
you _want_ to change the scheduler and not the code that honour the
need_resched bit. Of course I am supposing the checks itself are not the
source of the slowdown.
Andrea
--- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail majordomo@rtlinux.cs.nmt.edu OR
echo "unsubscribe rtl <Your_email>" | mail majordomo@rtlinux.cs.nmt.edu
----
For more information on Real-Time Linux see:
http://www.rtlinux.org/~rtlinux/