Messages in this thread | | | Date | Mon, 17 Oct 2005 21:39:20 +0200 | From | Eric Dumazet <> | Subject | Re: VFS: file-max limit 50044 reached |
| |
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/ > >
- 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/
| |