lkml.org 
[lkml]   [2004]   [Oct]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U0
From
On Thu, Oct 14, 2004 at 11:52:52AM -0700, Daniel Walker wrote:
> When I was reviewing this it seemed like it would be possible to keep
> RCU anonymous by moving the callback processing out of the tasklet . The
> reason it was moved into a tasklet was to reduce latency. But if you
> serialize it like you have, aren't you removing all the benefits of the
> RCU type lock in those section that are converted to the new API ?

What Ingo is doing now is mostly like a temporary fix for dealing with
this issue. Simple backing with a normal mutex should be sufficient for
protecting that access. RCU is still an open problem.

> Why not have a per cpu mutex instead of a per variable per cpu mutex?
> I'm not sure what the trade off are, except size.

It's a read-mostly read/write lock. N number of real processors can
do N number of read locks. That structure needs to be emulated somehow
and a per CPU mutex is probably the correct method of getting it.
It's just a matter of how. I did suggest something in my project
announcement.

I don't know if it's crack smoking or not. :)

bill

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

\
 
 \ /
  Last update: 2005-03-22 14:07    [W:0.616 / U:13.384 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site