Re: VFS: file-max limit 50044 reached

[Eric Dumazet]

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

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