Re: VFS: file-max limit 50044 reached

[Linus Torvalds]

On Mon, 17 Oct 2005, Eric Dumazet wrote:
> 
> Thats strange, because on my tests it seems that I dont have one reschedule
> for 'maxbatch' items. Doing 'grep filp /proc/slabinfo' it seems I have one
> 'schedule' then filp count goes back to 1000.

Hmm.

I think you're right, but for all the wrong reasons.

"maxbatch" ends up not actually having any real effect in the end: after 
the tasklet ends up running in softirqd, softirqd will actually keep on 
calling the tasklet code until it doesn't get rescheduled any more ;)

So it will do "maxbatch" RCU entries, reschedule itself, return, and 
immediately get called again.

Heh.

The _good_ news is that since it ends up running in softirqd (after the 
first ten times - the softirq code in kernel/softirq.c will start off 
calling it ten times _first_), it can be scheduled away, so it actually 
ends up helping latency.

Which means that we actually end up doing exactly the right thing, 
although for what appears to be the wrong reasons (or very lucky ones).

The _bad_ news is that softirqd is running at nice +19, so I suspect that 
with some unlucky patterns it's probably pretty easy to make sure that 
ksoftirqd doesn't actually run very often at all! 

Gaah. So close, yet so far. I'm _almost_ willing to just undo my "make 
maxbatch huge" patch, and apply your patch, because now that I see how it 
all happens to work together I'm convinced that it _almost_ works. Even if 
it seems to be mostly by luck(*) rather than anything else.

		Linus

(*) Not strictly true. It may not be by design of the RCU code itself, but 
it's definitely by design of the softirq's being designed to be robust and 
have good latency behaviour. So it does work by design, but it works by 
softirq design rather than RCU design ;)
-
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/