Messages in this thread | | | Subject | RE: printk_ratelimit and net_ratelimit conflict and tunable behavior | Date | Thu, 28 Feb 2008 10:19:02 -0600 | From | "Hawkes Steve-FSH016" <> |
| |
Andrew Morton wrote:
> This patch causes a large and nasty reject. > Probably because you patched 2.6.24. We're developing 2.6.25 now, and > the difference between the two is very large inded. Please raise patches > against Linus's latest tree?
Will do. I'm learning the process. I assume Linus's latest tree is the one listed as the latest prepatch for the stable Linux kernel tree.
Andrew Morton wrote:
> > struct printk_ratelimit_state { > > + unsigned long toks; > > + unsigned long last_jiffies; > > + int missed; > > + int limit_jiffies; > > + int limit_burst; > > + char const *facility; > > +}; > > I find that the best-value comments one can add to kernel code are to the > members of structures. If the reader understands what all the fields do, the > code becomes simple to follow.
Agreed. Although the current kernel source doesn't document these attributes, there's no reason I couldn't add documentation for them.
Andrew Morton wrote:
> > int net_ratelimit(void) > > { > > - return __printk_ratelimit(net_msg_cost, net_msg_burst); > > + static struct printk_ratelimit_state limit_state = { > > + .toks = 10 * 5 * HZ, > > + .last_jiffies = 0, > > + .missed = 0, > > + .limit_jiffies = 5 * HZ, > > + .limit_burst = 10, > > + .facility = "net" > > + }; > > + > > + return __printk_ratelimit(net_msg_cost, net_msg_burst, &limit_state); > > I don't get it. There's one instance of limit_state, kernel-wide, and > __printk_ratelimit() modifies it. What prevents one CPU's activities from > interfering with a second CPU's activities?
The state is protected by the spinlock in __printk_ratelimit, like it is in the current kernel. Am I missing something?
| |