lkml.org 
[lkml]   [2005]   [Oct]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-10-17 21:42    [W:0.110 / U:1.024 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site