Re: [patch] Latency Tracer, voluntary-preempt-2.6.8-rc4-O6

[Lee Revell]

On Fri, 2004-08-13 at 06:31, Ingo Molnar wrote:
> * Lee Revell <rlrevell@xxxxxxxxxxx> wrote:
> 
> > > >   http://redhat.com/~mingo/voluntary-preempt/voluntary-preempt-2.6.8-rc4-O6
> > 
> > Ugh, this is a bad one:
> > 
> > preemption latency trace v1.0
> > -----------------------------
> >  latency: 506 us, entries: 157 (157)
> >  process: evolution/3461, uid: 1000
> >  nice: 0, policy: 0, rt_priority: 0
> > =======>
> >  0.000ms (+0.000ms): get_random_bytes (__check_and_rekey)
> [...]
> >  0.493ms (+0.001ms): local_bh_enable (__check_and_rekey)
> 
> indeed this is a new one. Entropy rekeying every 300 seconds. Most of
> the overhead comes from the memcpy's - 10 usecs a pop!
> 

I have attached a patch that effectively disables extract_entropy.  I am
adding Theodore T'so to the cc: list as he is the author of the code in
question.

For the time being this hack is required to avoid ~0.5 ms
non-preemptible sections caused by the excessive memcpy's in
extract_entropy.

I am not a crypto expert, but it seems like there would be a zero-copy
solution.  Alternatively, a way to tell the system that we just don't
need THAT much entropy would be acceptable.  I would gladly trade
predictable TCP sequence numbers for the ability to do low latency
audio.

Ingo, can you add this to -P3, unless someone proposes a better way?

Lee

--- linux-2.6.8.1/drivers/char/random.c	2004-08-14 06:54:48.000000000 -0400
+++ linux-2.6.8.1-P2/drivers/char/random.c	2004-08-16 19:26:29.000000000 -0400
@@ -1354,6 +1354,8 @@
 static ssize_t extract_entropy(struct entropy_store *r, void * buf,
 			       size_t nbytes, int flags)
 {
+	return nbytes;
+    
 	ssize_t ret, i;
 	__u32 tmp[TMP_BUF_SIZE];
 	__u32 x;




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