LKML Archive on
help / color / mirror / Atom feed
From: Steven Hawkes <>
Subject: Re: printk_ratelimit and net_ratelimit conflict and tunable behavior
Date: Thu, 28 Feb 2008 10:10:39 -0600	[thread overview]
Message-ID: <> (raw)

Joe Perches wrote:

> On Mon, 2008-02-25 at 17:49 -0600, Hawkes Steve-FSH016 wrote:
> > Are you saying the few lines of code to handle changes to the tunables
> > aren't worth keeping?
> Yes.
> I think the tunables, if needed at all, should be set by modifying
> the struct and the call might as well be:
> bool __printk_ratelimit(struct printk_ratelimit_state *state)

The tunables are used in the current rate-limiting algorithm. Wouldn't
incorporating them into the structure require protecting modification of the
tunables by the same spinlock used in the rate limiting? That could be done
by pulling the spinlock variable out into printk_ratelimit() and
net_ratelimit() and into the struct (the spinlock is needed internal to
__printk_ratelimit to allow the spin_unlock() done right before actually
printing the message). That seems a bit more complex.

Or are you suggesting copying the tunables into the struct each time
__printk_ratelimit() is called? I was looking at them as not part of the
state of rate limiting, but rather external attributes controlling rate

Joe Perches wrote:

> Another quibble is not directed to your change because it's
> preexisting but "tok" isn't a good name and may not even need
> to be in the structure.  It does save a multiply though.

I agree the original name can be improved upon.

The toks state variable is needed because it actually maintains the current
rate-limiting water level, so to speak. The "bucket" is initially filled to
its capacity, ratelimit_jiffies * ratelimit_burst. Each time
__printk_ratelimit is called, water gets added to the bucket in proportion
to the time since the last call (capped by the capacity of the
bucket). Prints are allowed as long as the bucket has at least
ratelimit_jiffies of water left. Each allowed print sucks a
ratelimit_jiffies amount out of the bucket. (At least I think that's the way
the current kernel works; it wasn't immediately obvious to me.)

             reply	other threads:[~2008-02-28 16:10 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-28 16:10 Steven Hawkes [this message]
  -- strict thread matches above, loose matches on Subject: below --
2008-02-25 20:36 Steven Hawkes
2008-02-25 23:45 ` Andrew Morton
2008-02-28 16:19   ` Hawkes Steve-FSH016
2008-02-28 18:39     ` Andrew Morton
2008-02-19 21:30 Hawkes Steve-FSH016
2008-02-21  6:32 ` David Miller
2008-02-21  7:00   ` Joe Perches
2008-02-25 15:47     ` Hawkes Steve-FSH016
2008-02-25 20:02       ` David Miller
2008-02-25 20:13       ` Joe Perches
     [not found]         ` <>
2008-02-26  0:04           ` Joe Perches

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \
    --subject='Re: printk_ratelimit and net_ratelimit conflict and tunable behavior' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).