Subject: Re: [patch] Real-Time Preemption, -RT-2.6.12-rc3-V0.7.46-01
From: Lee Revell <rlrevell@joe-job.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: linux-kernel@vger.kernel.org, Daniel Walker <dwalker@mvista.com>
In-Reply-To: <20050504082241.GA13380@elte.hu>
References: <20050325145908.GA7146@elte.hu> <20050331085541.GA21306@elte.hu>
	 <20050401104724.GA31971@elte.hu> <20050405071911.GA23653@elte.hu>
	 <20050421073537.GA1004@elte.hu> <20050422062714.GA23667@elte.hu>
	 <1114903693.12664.9.camel@mindpipe>  <20050504082241.GA13380@elte.hu>
Content-Type: text/plain
Date: Wed, 04 May 2005 11:05:34 -0400
Message-Id: <1115219134.935.20.camel@mindpipe>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1246
Lines: 34

On Wed, 2005-05-04 at 10:22 +0200, Ingo Molnar wrote:
> * Lee Revell <rlrevell@joe-job.com> wrote:
> > it looks like we are finally getting close to the lower limit 
> > that can be achieved with PREEMPT_DESKTOP ... It's only 127 usecs, and 
> > IIRC you mentioned previously that this code path can't be made 
> > preemptible in !PREEMPT_RT.
> 
> yeah, signal delivery will have to stay atomic in !PREEMPT_RT kernels.
> 

OK.  I found a few more.

When umounting, shrink_dcache_sb() will produce a 3-4 ms. bump.  However
it's not clear this can be made preemptible.  AFAICT the whole thing
needs to be under the dcache_lock.  This one is pretty obvious so I'm
not attaching a trace.

There's also still one path in the VM related to page freeing that can
produce ~500 usec latencies but I don't have a trace handy now.

> > Since Mingming's patch will have to live in -mm for a while, can it be 
> > added to the RT patchset as well?
> 
> i think so - i'll add it to the next patch.

OK, great.

Lee

-
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/