Re: VFS: file-max limit 50044 reached

[Eric Dumazet <dada1@cosmosbay.com>]

Linus Torvalds a écrit :
> 
> 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.
> 

:)

What about call_rcu_bh() which I left unchanged ? At least one of my 
production machine cannot live very long unless I have maxbatch = 300, because 
of an insane large tcp route cache (and one of its CPU almost filled by 
softirq NIC processing)

> 		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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 
>