Dipankar Sarma a écrit :
> On Mon, Oct 17, 2005 at 09:16:25AM -0700, Linus Torvalds wrote:
> 
>>>Absolutely. Keeping a count of (percpu) queued items is basically free if kept
>>>in the cache line used by list head, so the 'queue length on this cpu' is a
>>>cheap metric.
>>
>>The only downside to TIF_RCUUPDATE is that those damn TIF-flags are 
>>per-architecture (probably largely unnecessary, but while most 
>>architectures don't care at all, others seem to have optimized their 
>>layout so that they can test the work bits more efficiently). So it's a 
>>matter of each architecture being updated with its TIF_xyz flag and their 
>>work function.
>>
>>Anybody willing to try? Dipankar apparently has a lot on his plate, this 
>>_should_ be fairly straightforward. Eric?
> 
> 
> I *had*, when this hit me :) It was one those spurt things. I am going to
> look at this, but I think we will need to do this with some careful
> benchmarking.
> 
> At the moment however I do have another concern - open/close taking too
> much time as I mentioned in an earlier email. It is nearly 4 times
> slower than 2.6.13. So, that is first up in my list of things to
> do at the moment.
> 

<lazy_mode=ON>
Do we really need a TIF_RCUUPDATE flag, or could we just ask for a resched ?
</lazy_mode>

This patch only take care of call_rcu(), I'm unsure of what can be done inside 
call_rcu_bh()

The two stress program dont hit OOM anymore with this patch applied (even with 
maxbatch=10)

Eric