Re: VFS: file-max limit 50044 reached

[Linus Torvalds]

On Tue, 18 Oct 2005, Dipankar Sarma wrote:

> On Mon, Oct 17, 2005 at 08:01:21PM +0200, Eric Dumazet wrote:
> > Dipankar Sarma a écrit :
> > >On Mon, Oct 17, 2005 at 09:16:25AM -0700, Linus Torvalds wrote:
> > >
> > 
> > <lazy_mode=ON>
> > Do we really need a TIF_RCUUPDATE flag, or could we just ask for a resched ?
> > </lazy_mode>
> 
> I think the theory was that we have to process the callbacks,
> not just force the grace period by setting need_resched.
> That is what TIF_RCUUPDATE indicates - rcus to process.

I'm having second thoughts about that, since the problem (in SMP) is that 
even if the currently active process tries to more proactively handle RCU 
events rather than just setting the grace period, in order to do that 
you'd still need to wait for the other CPU's to have their quiescent 
phase.

So the RCU queues can grow long, if only because the other CPU's won't 
necessarily do the same.

So we probably cannot throttle RCU queues down, and they will inevitably 
have to be able to grow pretty long. 

> Hmm.. I am supprised that maxbatch=10 still allowed you keep up
> with a continuously queueing cpu. OK, I will look at this.

I think it's just because it ends up rescheduling a lot, and thus waking 
up softirqd.

The RCU thing is done as a tasklet, which means that
 - it starts out as a "synchronous" softirq event, at which point it gets 
   called at most X times (MAX_SOFTIRQ_RESTART, defaults to 10)
 - after that, we end up saying "uhhuh, this is using too much softirq 
   time" and instead just run the softirq as a kernel thread.
 - setting TIF_NEEDRESCHED whenever the rcu lists are long will keep on 
   rescheduling to the softirq thread much more aggressively.

See __do_softirq() for some of this softirq (and thus tasklet) handling.

I suspect it's _very_ inefficient, but maybe the bad case triggers so 
seldom that we don't really need to care. 

		Linus