[Twisted-Python] Scalability of timers

[dw+twisted-python at hmmz.org]

On Sun, Aug 10, 2014 at 02:51:02PM -0700, Tobias Oberstein wrote:

> But the coalescing you describe would also apply to those implicit
> timers (created from select(timeout = ..) within the Linux kernel)?

It applies to all kernel timers not created by realtime processes.


> This is all fine. But how do I _explicitly_ limit the rate at which
> select() is called to say 1000Hz (at the expense of timer precision)?

> I don't want to let the box hit it's syscall rate limit. Because the
> box will spend a fair amount of resources for context switching all
> the time with to real gain.

>From a reading of http://lwn.net/Articles/296578/, at time of writing
the default select() implementation coalesces sub-second timeouts to
50us boundaries, and this can be adjusted via prctl(PR_SET_TIMERSLACK)
(http://linux.die.net/man/2/prctl) on a per-process basis.

That article is from 2008, and though the relevant kernel code seems to
match the article content, a huge amount of power-efficiency related
changes went into the kernel since that time. My assumption is nowadays
the kernel rounds more aggressively than the default of 50us documented
by that article.

Short answer is yes, you can set the max hz of select(), but in all
likelihood you won't have to. As always, benchmarking and profiling real
code might reveal this to be a non-issue.


David

> 
> Thanks for your hints and patience,
> Tobias
> 
> > 
> > 
> > On Sun, Aug 10, 2014 at 05:16:51AM -0700, Tobias Oberstein wrote:
> > > Hi,
> > >
> > > I have a question regarding scalability of timers in Twisted.
> > >
> > > Say I have a massive number of periodic timers (lets say each with period 1s,
> > but all slightly time shifted to each other).
> > >
> > > As far as I understand, timers are implemented ultimately by setting the
> > timeout parameter when calling into OS select/poll/epoll/kqueue.
> > >
> > > If this  is true, then the number of timers scales linearly with the number of
> > syscalls. This can get limiting (the total number of syscalls a Linux box can
> > sustain is a couple of 100k's per second). As more and more timers are setup,
> > the timeout essentially will approach 0. On the upside, timers will fire
> > precisely.
> > >
> > > However, say I am fine with a precision of 1ms.
> > >
> > > Is there a way that limits the syscall rate to 1000/s (given no FD activity
> > happens) _independently_ of the number of timers setup?
> > >
> > > Timers that fall into a certain ms slice would all fire roughly at the same time
> > (still ordered).
> > >
> > > Is that possible?
> > >
> > > Thanks,
> > > Tobias
> > >
> > > _______________________________________________
> > > Twisted-Python mailing list
> > > Twisted-Python at twistedmatrix.com
> > > http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
> > 
> > _______________________________________________
> > Twisted-Python mailing list
> > Twisted-Python at twistedmatrix.com
> > http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python
> 
> _______________________________________________
> Twisted-Python mailing list
> Twisted-Python at twistedmatrix.com
> http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python